
reality asserting itself 

you are here / maybe 



you are here / maybe 



Sometimes people ask me what the deal is with Gowanus 
Heights http://www.gowanusheights.info/ . Gowanus Heights began after I 
spent 15 minutes one day poking around 

Everyblock http : / /www . everybiock .com/ try to figure which neighbourhood 
the block I live on belongs to. I still don't know. 

The experience looked something like this: 
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These are not Everyblock's neighbourhood shapes. They are the alpha 
Shapes http : / /code . f lickr . net / 2 008/10/30 /the-shape-of -alpha/ derived 

from geotagged photos on Flickr, plus one for Gowanus 

Heights http: / /www. gowanusheights .info/data/ . You know, in case you ever 
found yourself wondering: "What exactly is BoCoCa?" We really do live at the 
overlap of four neighbourhoods so I was less bothered by the mess of choices than 
by apparent inability — or unwillingness — of Everyblock to pick one. Or to let me 
pick one. 

At the time I started joking with people that I was just going to create a new 
neighborhood since apparently we live in an instance of China Meiville's 
"breach" https://en.wikipedia.org/wiki/The_City_%26_the_City . The 
running candidates were "Cobble Gardens" and "Cobblewanus". Over drinks with a 
long-time neighbourhood local it was correctly pointed out that "Gowanus Heights" 
is more in line with the history of naming conventions in New York City. 



Thus was it ever. At least if I have my way. 



This is a thing I wrote http: //lists .w3.org/Archives/Public/public- 
geolocation/2008Jun/0059.html , a couple years ago: 



Never mind so-called disputed places (Kashmir, the West Bank, Cyprus, 
etc.) all neighbourhoods are "disputed" around the edges. (This is often 
true of localities, as well.) 

For example, the rough consensus in San Francisco is that Delores street 
is the dividing line between the Mission and Noe Valley. That said there 
are those people who may live on the one side of the line and very much 
believe themselves to be living on the "other". Our experience has been 
that there are few better ways to pick a fight than to tell someone what 
neighbourhood they are in (and being wrong). 

There is also the problem where the data simply doesn't exist yet or it is 
just old and dusty, sometimes wrong, and often plain weird : "Manhattan 
Valley", anyone? 

This is further compounded by the lack of ideas/tools/infrastructure for 
reflecting changes (both socially and politically) but, ultimately, those 
are both somewhat tangential. 



This blog post is really about those tools I talked about a million years ago. 

Last week Kellan http://www.iaughingmeme.org/ and I were 
bemoaning the still generally shit state of reverse- 

geocoding http://biip.tv/oreiiiy-where-20-conference/catt-cope-going- 

photos-975454 in 2013. Eventually we wondered why there wasn't a tool (an 
"app" to use the lingo of the young folk) which would use their magic-sky-device's 
GPS capability and ask people where they were at that moment and collected that 
data for further processing, like generating new alpha-style shapefiles. 



Kellan's been talking about it as being like a 



game http: //laughingmeme. org/2 0 13 /02/03/are-you-here-a-f eature-on-the- 

side/ and I've been saying the thing is essentially "geocorrections" as a service. 
So I started trying to build it. It's called you are 

here http://straup.github.com/youarehere/ . It's is very much a work in 
progress and there is nothing public to play with yet but you can follow along on 

Github https://github.com/straup/youarehere . 

Conceptually there are four big pieces: 

• Matt Biddulph'sflickrgeocoder- 

java https://github.com/mattb/flickrgeocoder-java daemon. 

Matt built a happy little httpony around the Java Topology 

Suite http://tsusiatsoftware.net/jts/main.html and 

GeoTools http://www.geotoois.org/ libraries which do point in 
polygon queries. That's all it does. When he first wrote it the code was 
hard-coded to use the second release of the Flickr alpha shapes. Since 
then he's updated it to accept an arbitrary list of shapefiles on the 
command line. That's super-good and I'll talk about it more, in a 
moment. My tiny contribution so far has been a patch to enable CORS 
headers http://enabie-cors.org/ when sending back results. 
Eventually I hope to add support for 

GeoJSON http://www.geojson.org/ results but I am still not much 
of a Java weenie so it might take a few false starts before that's done. 

• A web application ( the you are 

here http://straup.github.com/youarehere/ part) that queries 

the reverse geocoder and records people's choice. 

That's the piece I've been working on for the last week. This is the part 
that let's you say a given spot (a latitude and a longitude) is contained 
by a given place with a unique ID. Currently that means a Where on 
Earth (or WOE) ID http://woe.spum.org/ but the important thing 
to remember is that you could use any dataset with enough points to 
create a polygon. David Blackman's just released geoplanet- 



Concordance https : //github.com/blackmad/geoplanet- 

conoordance for mapping Geonames IDs and WOE IDs feels 
important that way. Don't forget that the Flickr alpha shapes were 
derived from a twisty maze of overlapping 

squares http://www.slideshare.net/straup/aware-of-only-one- 
voioe . 

• Exporting the data as publicly available and liberally licensed dumps 
(or eventually pubsub- 

Style https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pat1 

broadcast streams). 

Fve been trying to imagine what this might look like. "Good enough" 
might just be daily dumps written to a GitHub repository. Or maybe 
something something pubsub-ish in nature. It wouldn't be that hard to 
add support for 

pubsubhubbub https://code.google.eom/p/pubsubhubbub/ -Style 

notifications over HTTP but in between the other moments Fve been 
wondering what sort ofRedis pubsub-as-a- 

service http://redis.io/topics/pubsub type services there are , 
preferably ones where the barrier to use for people subscribing is 
minimal-to-none. Which means: Not forcing people to sign upforyet- 
another account or have to be billed to use it. The jury is still out on 
that one. 

• Processing that data and feeding it back into Matt's reverse- 
geocoding tool. 

This could mean generating new 

alpha http://code.flickr.net/2008/10/30/the-shape-of- 
alpha/ shapes, 

beta https : //github.com/simplegeo/betashapes /blob/master /BLOGPOE 

shapes or even 

gamma http: / /mike . teczno . com/notes /gammashapes-for- 

obama . html shapes. Or all of them. The point is to make shapes for 



all the things. Most of the things that Eric Fischer has been 
making http: //www. theatlanticcities . com/arts-and- 
lifestyle/2012/08/mapmaker-artist-or-prograramer/3132/ in the 

last few years are derived from nothing more than an enormous bag of 
dots, so we are bounded only by our imagination. 

Depending in how you're counting things there's a fifth item or a non-trivial 
aspect of the second item which I haven't mentioned yet. It's not clear to me. 
Specifically whether the code should try to be smart and apply suitable rankings to 
future queries for a user. As it is, the site is more about data collection than data 
crunching; more about you answering questions rather than answering questions for 
you. It doesn't necessarily need to be that way but it's been a handy constraint 
(simply trusting whatever Matt's thing says) since I only have an hour or so in the 
mornings to work on this. 

On the other hand if, as I've been imagining, I add an API to the site that 
other services could use 

(privatesquare http://straup.github.com/privatesquare/ is an obvious 

candidate) then there's rapidly diminishing value in forcing people to say "No, this 
is what I meant! " Unless the whole thing is framed as a game, as Kellan suggests. 

Maybe? Maybe not? 

If this all sounds suspiciously like what we were saying when we talked 
about corrections and the alpha shapes and reverse-geocoding at 

Flickr http : / /code . f lickr . net/category /geo/ that's because it is. I apologize 

that we never got that out the door. It was clear as day to me but it was also 
interrupted by all the other things going on and then I forfeited my right to do 
anything about it by 

leaving http: //www. aaronland.info/weblog/2009/ll/06/thatisall/#f lickr . 
I have no idea what or how they're thinking about this problem these days but the 
fact that the geo corrections API 

methods http: //www. flickr.com/services/api/flickr .photos .geo. correctLoc, 
have been updated, without warning, to require that you include a foursquare ID 
suggests they're doing ... something? 



I mentioned Matt's thing. I made a little run . sh script to hide the usual 
rain-dancing required to start a Java thing so all you need to do is pass the port 
number you want your server to listen on and the list of shapes to query. Like this: 

# Start one server (on port 5000) to query only neighbourhoods 
$> you are in f lickrgeocoder- java, in the corner is a factory 
$> run.sh 5000 \ 

src/main/resources/ ... /f lickrshapesneighbourhoods/OGRGeoJSON . shp \ 
src/main/resources/ ... /gowanus_heights/gowanus-heights . shp 

# Start a second server (on port 9000) to query localities 

$> you are in f lickrgeocoder- java, in the corner is an abstraction 
$> run.sh 9000 \ 

src/main/resources/ . . . /f lickr_shapes_localities/OGRGeoJSON. shp 

See the way we're able to squirt in the shapefile for Gowanus Heights? That 
allows us to easily mix-and-match data sources. Most of the examples in this blog 
post assume the Flickr shapefiles http: //code, fiickr.net/2012/10/24/2273/ 
but you could use anything, really. I am still waiting for Matt to accept my patch to 
have Null Island included https : / /github . com/mattb/f lickrgeocoder- 
java/puii/3 with the default distribution but you could just as easily imagine 

using Pleiades http://sgillies.net/blog/1164/pleiades-tags-on-flickr- 
continued as a data source or La Lengua http://burritojustice.com/la- 
lengua/ (Gowanus Heights' sister neighbourhood) or Miquel Hudin and Wendy 
MacNaughton's Mini Tenders http://aaronland.info/minitenders/ . That's 
quite good. 

It's not entirely clear to me if running multiple servers is the correct 
approach. My gut tells me it is because each daemon is constrained largely by the 
amount of RAM necessary to load everything in to memory (plus operating costs) 
which means you could distribute the different place types across a variety of 
machines and pool them as needed. Given that the application code talks to the 
daemons over HTTP it would be easy enough to stick a Squid machine (or 
equivalent) were that ever necessary. 

It is also helpful in narrowing the scope of the query. Which is a nice 
separation of concerns that follows the model that we used at Flickr: 

• A hierarchy can be derived independent of the query to convert a 



lat,lon to place ID (in this case a WOE ID) 

• If I can't figure out what neighbourhood you're in because you're in the 
back woods of Idaho I should at least be able to figure out that you're 
in Idaho or if not that then the US. Hence the filtering of query by place 
type. 

As of this writing the site still only queries neighbourhoods but you can 
override that by passing a filter parameter. For example... New Jersey? 
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The Flickr data is 

weird http : / /www .museumsandtheweb . com/mw2 00 9 /papers/cope/cope . html . 

Given how large and floppy metropolitan areas often are the site should probably be 
using the "donut hole http://code.fiickr.net/2009/01/12/iiving-in-the- 
donut-hoie/ " shapes for localities where they're available. It's also important to 
remember that the underlying dataset we were working with routinely told us stuff 



like "Brooklyn is a county" so whatcha gonna do? The point is not whether the data 
is correct. The point is that there's a way to express an opinion about 

it http: //code. f lickr.net/2 0 08/08 /08/location-keeping-it-real-on-the- 
streets-yo/ 



Because I am pretty sure this is not Lomita Park. 
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You can also indicate a perspective when you say where a place is. Valid 
options are "local" and 

"tourist " http : / /www . f lickr . com/photos /walkings f /sets/72157624209158632/ 

and "none of your business". 




Or ?f ilter=countries. It turns out that people like to take pictures on 
boats in the US . 




Speaking of which, did I mention Null 

Island http://www.nullisland.com/ ? 
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It's still a ways from being public-ready thing but it basically works. There 
are permalinks for every correction (lovingly hand-crafted with artisanal 
integers http : / /www . brookiyninteger s . com/ , of course) and list views by date 
and WOE ID and, if enabled, by user. 

One of the goals — the primary goal — is to release all the data publicly 
because [insert rant about geo data here]. It is equal parts sad-making and hate- 
making that we're all still stuck suffering the lack of a comprehensive and open 
dataset for places. It's 2013 and maybe we should be focusing on features instead of 
subtle variations on the theme of data/vendor lock-in? Crazy, I know. 

The site uses the Twitter http : / /www . twitter . com/ API as a single- 
sign-on provider mostly just as a barrier to prevent bored-in-a-meeting style abuse 
but also to let people consuming the data make their own judgements based on the 
number of corrections a user has made, their distribution over space and time and so 
on. The question I'm having is not whether to include their actual Twitter usernames 



in the data dumps but whether to include an obfuscated identifier. An encrypted 
hash of their Twitter username, for example. 

This is what the site says about the subject, right now: 



The idea is for all of this data to released publicly under as liberal a 
license (for the purposes of re-use) as is not-annoying. 

Data dumps will not contain your (Twitter) username but might contain 
an obfuscated user identifier. This is so that people consuming the data 
can make better informed decisions about which corrections to trust. Or 
not. I am still working through the ways in which that might get creepy. 

The point is not to promote a naked Facebook-esque mirror world but to 
find an acceptable place where privacy interests and transparency can 
exist. That might not be possible and if that's the case then a user's 
privacy will take precedence. 

The same issues apply to the question of recording and displaying IP 
addresses. The goal in both cases is to provide some hooks for someone processing 
the data to gauge the value of a person's contribution. It's a sideways kind of signal- 
noise throttling since it assumes that anyone/thing that is too noisy will just be 
dropped in the floor. 

In the meantime I've add feature flags so that the recording of IP addresses 
can be disabled entirely and I may just hash them all (with a site-specific secret) on 
their way in to the database. 




I'll get something up and running in public shortly. I would like for this to be 
more than a prototype. Whether people use you are 

here http://straup.github.com/youarehere/ or not the larger project is 
important. As Kellan points out we have "a 100mil+ people carrying GPS device in 
their pockets and we have to buy expensive proprietary data to find out about the 
shape of where we live" . 



We should fix that. 



Update (April 2013): 
youarehere.spum.org http://youarehere.spum.org went live on April 01, 
2013. It's still not polished the way it should be (and notably lacks a public API 
still) but it works. Data dumps are being collected and republished on Github at 
https:llgithub.com/strauplyouarehere- 

data https://github.com/straup/youarehere-data . 
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Things I Have Written Elsewhere 

#1 359954000 

Albers boxes 



Albers boxes 



This post was originally written for the Cooper-Hewitt 

Labs http://labs.cooperhewitt.org/2013/albers-boxes/ Weblog. 

We have a lot of objects in our 
collection http://coiiection.cooperhewitt.org/ . Unfortunately we are also 
lacking images for many of those same 

Objects http://labs.cooperhewitt.org/2013/curatorial-poetry/ . There 
are a variety of reasons why we might not have an image for something in our 
collection. 

• It may not have been digitized yet ( aka "had its picture taken "). 

• We may not have secured the reproduction rights to publish an image 
for an object. 

• Sometimes, we think we have an image for an object but it's managed 
to get lost in the shuffle. That's not awesome but it does happen. 

What all of those examples point to though is the need for a way to convey 
the reason why an image can't be displayed. Traditionally museum websites have 
done this using a single stock (and frankly, boring) image-not-available 
placeholder. 

We recently — finally — updated the site to display "list" style results with 
images, by default. Yay! 

In the process of doing that we also added two different icons for images 
that have gone missing and images that we don't have, either because an object 
hasn't been digitized or we don't have the reproduction rights which is kind of like 
not being digitized. This is what they look like: 



a 



The not digitized icon is courtesy Shelby Blair (The Noun 

Project) http://thenounproject.eom/noun/question/#icon-Wo5202 

The missing image icon is courtesy Henrik LM (The Noun 

Project) http: //thenounproject.com/noun/question/#icon-No8325 



So that's a start but it still means that we can end up with pages of results 
that look like this: 
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What to do? 



We have begun thinking of the problem as one of needing to develop a 
visual language (languages?) that a person can become familiar with, over time, 
and use a way to quickly scan a result set and gain some understanding in the 
absence of an image of the object itself. 

Today, we let some of those ideas loose on the website (in a controlled and 
experimental way). They're called "Albers boxes." Albers boxes are a shout-out 
and a whole lot of warm and sloppy kisses for the artist Josef 

Albers http://collection.cooperhewitt.org/people/18052071/ and his 

book about the Interaction of 

Color http : / /openlibrary . org/works /0L2 2 8617 7W/Interaction_of _color . 
This is what they look like: 




The outer ring of an Albers box represents the department that an object 
belongs to. The middle ring represents the period that an object is part of. The 
inner ring denotes the type of object. When you mouse over an Albers box we 
display a legend for each one of the colors. 

We expect that the Albers boxes will be a bit confusing to people at first 
but we also think that their value will quickly become apparent. Consider the 
following example. The Albers boxes allow us to look at this set of objects and 
understand that there are two different departments, two periods and three types of 
objects. 

Or at least that there are different sorts of things which is harder to do when 
the alternative is a waterfall of museum-issued blank-faced placeholder images. 



Things we acquired in 1977 




The Albers boxes are not enabled by default. You'll need to head over to 
the new "experimental" 



Section http: //collection. cooperhewitt.org/experimental/#a of the 
collections website and tell us that you'd like to see them. Experimental features 
are, well, experimental so they might go away or change without much notice but 
we hope this is just the first of many. 



Enjoy! 



Also: If you're wondering how the colors are chosen take a look at this lovely blog post from 

2007 http://biog.doppir.com/2007/10/23/in-rainbows/ from the equally lovely kids at Dopplr. They had the right idea 
way back then so we're just doing what they did! 
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Things I Have Written Elsewhere 
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All your color are belong to Giv 



"All your color are belong to Giv" 




This post was originally written for the Cooper-Hewitt 
Labs http://labs.cooperhewitt.org/2013/giv-do/ Weblog. 

Today we enabled the ability to browse the collections website by 

Color http://collection.cooperhewitt.org/objects/colors/ . Yay! 

Don't worry — you can also browse by 

Colour http://collection.cooperhewitt.org/objects/colours/ but since the 

Cooper-Hewitt is part of the Smithsonian I will continue to use US Imperial 
Fahrenheit spelling for the rest of this blog post. 



Objects with images now have up to five representative colors attached to 
them. The colors have been selected by our robotic eye machines who scour each 
image in small chunks to create color averages. We use a two- pass process to do 
this: 

• First, we run every image through Giv 

Parvaneh's http://www.givp.org/ handy color analysis tool 

RoyGBiv https://github.com/givp/RoyGBiv . Giv's tool calculates 

both the average color of an image and a palette of up to five 
predominant colors. This is all based on the work Giv did for version 
two of the Powerhouse Museum's Electronic 

Swatchbook http : / /www . f reshandnew .org/2009/0 7 /electronic- 
swatchbook-version-2-lots-more-public-domain-swatches- 
search-by-color-2/ , back in 2009. 

• Then, for each color in the palette list (we aren't interested in the 
average) we calculate the nearest color in the CSS3 color 
spectrum http: //www. w3 .org/TR/css3-color/#svg-color .We 
"snap " each color to the CSS3 grid, so to speak. 

We store all the values but only index the CSS3 colors. When someone 
searches the collection for a given color we do the same trick and snap their query 
back down to a managable set of 121 colors rather than trying to search for things 
across the millions of shades and variations of colors that modern life affords us. 

Our databases aren't set up for doing complicated color math across the 
entire collection so this is a nice way to reduce the scope of the problem, especially 
since this is just a "first draft". It's been interesting to see how well the CSS3 palette 
maps to the array of colors in the collection. There are some dubious matches but 
overall it has served us very well by sorting things in to accurate-enough buckets 
that ensure a reasonable spread of objects for each query. 

We also display the palette for the object's primary image on the object page 
(for those things that have been digitized) . 
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Color, or cokwr, U out of the attributes we're interested in exploring far collection browsing. Bearing in mind that only a fraction of 
our collection currently hat image*, here's a first pus. 

Objects with images now have up to five representative colors attached to them. The colors have been selected by our robotic eye 
machines who scour each image in small chunks to create color averages , These have then been harvested and "snapped" to Ibt grid 
of 121 difTerem colon - derived from the - below to nuke navigation a little easier. 
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We 're not being very clever about how we sort the objects or how we let you 
choose to sort the objects (you can't) which is mostly a function of knowing that the 
database layer for all of this will change soon and not getting stuck working on 
fiddly bits we know that we're going to replace anyway. 

There are lots of different palettes out 

there http: //observatory . designobserver . com/michaelbierut/ feature /chroma 

and as we start to make better sense of the boring technical stuff we plan to expose 
more of them on the site itself. In the process of doing all this work we've also 
released a couple more pieces of software on Github: 



Color-Utils https://github.com/straup/color-utils is a mostly a 



grab bag of tools and tests and different palettes that I wrote for 
myself as we were building this. The palettes are plain vanilla JSON 
files and at the moment there are lists for the CSS3 

colors http://www.w3. org/TR/css3-color/#svg-color , 

Wikipedia's list of Crayola crayon 

Colors http: //en.wikipedia . org/wiki/List_of_Crayola_crayon_colors 

the various shades of SOME -COLOR 

pages http : / /en . wikipedia . org/w/ index . php? 

title=Special%3ASearch&profile=default&search=shades+of+color&ful 
on Wikipedia, both as a single list and bucketed by family (red, green, 
etc.) and the Scandawegian Natural Colour 

System https : / /en. wikipedia. org/wiki/NaturalColorSystem 
mostly just because Frankie 

Roberto http : / /www . f r ankieroberto . com/ told me about it this 
morning. 

• palette-Server https://github.com/cooperhewitt/palette- 

server is a very small WSGI-compliant HTTP pony ( or 

"ftttpony https://pinboard.in/u:straup/t:httpony "jthatwraps 

Giv's color analyzer and the snap-to-grid code in a simple web 
interface. We run this locally on the machine with all the images and 
the site code simply passes along the path to an image as a GET 
parameter. Like this: 

curl 'http://localhost:8000?path=/users/asc/Desktop/cat.jpg' / python -m json.tool 
( 

"reference-closest " : "css3 ", 
"average" : { 

"closest": "#808080", 

"color": "#8e895a", 

}, 

"palette": [ 
< 

"closest": "#a0522d", 
"color": "#957d3t", 
> 



. . . and so on ... 



This allows us to offload all the image processing to third-party libraries and 
people who are smarter about color wrangling than we are. 

Both pieces of code are pretty rough around the edges so we'd welcome 
your thoughts and contributions. Pretty short on my TO DO list is to merge the code 
to snap-to-grid using a user-defined palette back in to the HTTP palette server. 




As I write this, color palettes are not exposed in either the 



API https://collection.cooperhewitt.org/api/methods/ or the Collections 
metadata dumps https://github.com/cooperhewitt/collection but that will 

happen in pretty short order. Also, a page to select objects based on a random color 
but I just thought of that as I was copy-paste-ing the links for those other things that 
I need to do first. . . 

In the meantime, head on over to the collections 

website http://collection.cooperhewitt.org/objects/colors/ and have a 
poke around. 
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prettymaps.local 



One of the early design decisions behind 
prettymaps http : / /prettymaps . stamen . com/ was: No moving pieces. Which 
really meant: No tile servers. 

Tile servers are yet-another point of failure and unlike most other special- 
case servers are usually meant to be exposed directly to the public. Stamen hadn't 
yet decided to tackle the tile serving problem in earnest as they have now with 
maps.stamen.com http : / /maps . stamen . com/ so we had the enforced luxury of 
choosing not to serve street level tiles for the entire world. 

prettymaps has global coverage from zoom levels two through ten and then 
goes down to zoom level 15 for something like two dozen individual cities. Which 
is still a lot of map tiles. Lots and lots of tiles. Gigabytes and gigabytes of tiny little 
files. But we pre-rendered them all and put them on an EBS volume that was 
attached to an EC2 server and told the world about the 

project http://stamen.com/projects/prettymaps and things seemed to work 
out okay. 

Eventually the site was moved from EC2 to a very big S3 "bucket". There is 
a lot to like about S3 but one of the things I like best is the ability to serve an 



entire website from a bucket http : / /aws . typepad . com/ aws /2 0 1 1 / 02 /host- 

your-static-website-on-amazon-s3 .html . You are Still Stuck serving your 

website from an ugly-ass AWS domain name but you can get around that with 
CNAMEs. For example: 

$> dig prettymaps.stamen.com 

; <<» DiG 9.8.3-P1 «» prettymaps.stamen.com 
;; global options: +cmd 
; ; Got answer : 

;; -»HEADER«- opcode: QUERY, Status: NOERROR, id: 44584 

;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 

;; QUESTION SECTION: 

; prettymaps . stamen . com. IN A 

; ; ANSWER SECTION: 

prettymaps.stamen.com. 1023 IN CNAME prettymaps.stamen.com.s3-website-us-east-l.amazonaws.com. 
prettymaps.stamen.com.s3-website-us-east-l.amazonaws.com. 60 IN CNAME s3-website-us-east-l . amazonai* 
s3-website-us-east-l.amazonaws.com. 23 IN A 72.21.215.203 

;; Query time: 126 msec 

;; SERVER: 10. 0.1. 1#5 3(10. 0.1.1) 

;; WHEN: Sat Mar 2 08:13:35 2013 

; ; MSG SIZE rcvd: 136 



From an operational point of view we were able to more or less remove (or 
more accurately delegate) all the moving pieces in one fell swoop. It's a little more 
complicated than that, but not really, and overall it has proven to be a nice and 
elegant solution to the problem of how you keep an historical project like this 
running without it interrupting the day-to-day needs of the present and in particular 
a busy client- services company. 

The Internet Archive should really make this possible for their S3 -style 
buckets as well. It's actual work to to enable but I reckon that if there was both a 
way to store things in the Archive and still keep them running on the internet people 
would start uploading stuff with tears of joy in their eyes. 




Fast-forward to a couple months ago when the Raspberry 
Pi http://www.raspberrypi.org/ I ordered finally arrived. If you haven't heard 
about the Raspberry Pi yet it's a credit-card sized Linux computer that costs about 
35$ and uses an SD card as its "hard drive". That's about it on the surface but it is 
the room for experimentation and the low cost of failure made possible by the 
availability of a real and proper computer at such a low price that is novel and 
exciting. 

It makes it possible to think about setting up silly projects like 
Loopr http : / / straup . github . com/ loopr / without also having to think about 
spending non-silly amounts of money on the hardware necessary to run them. 

Almost all the documentation makes it clear that you don't need anything 
bigger than a 4GB SD card to get started. After going through all the usual wax on 
wax off https: //www.youtube.com/watch?v=3PycZtfns_U exercises to get a 
basic system up and running I started wondering what you could do with a big 
honking SD card. You can get a 256GB card for about four hundred dollars so the 
Pi is still not quite the mythical 

"OpenStreetMap http://www.openstreetmap.org/ in a box" that everyone 
dreams of. It's both too expensive and too small to manage the raw XML data 



dump. Maybe the work to transition the data exports to use Google's Protocol 
Buffer format would make it possible? It's been a while since I've looked at that 
stuff... 

Still, you can get a 64GB SD card for about fifty bucks these days. So I did. 

I haven't done a lot of load testing on the Raspberry Pi. You could probably 
deploy one for a low-to-medium traffic website without worrying too much but I 
doubt I would use one to run a public map-tile server even if I still think about it 
every few days. I don't know how well PostGIS performs on a Pi but I know for a 
fact that TileStache http://tiiestache.org/ and 
gunicorn http : / /www . gunicorn . org/ both work like a charm (although 
libgevent isn't very happy and needs to replaced with eventlet). 

Eventually I started to think that maybe the most exciting part of the Pi, right 
now, wasn't running it in public but being able to use it as an archiving tool. Not a 
suspend-it-in-amber kind of archive but something like, or a variation on, the kind 
of living breathing shadow copy that things like parallel- 

flickr http: / /www. aaronland.info/weblog/2 012/02/ 14 /incentivize/#pda20 12 
or 

privatesquare http : / /nearf uturelaboratory . com/20 12 /0 1/22 /privatesquare/ 

try to be. Could I do that for prettymaps? 

And I totally can, it turns out. There's not a lot to show for that statement, 
though. The only thing to show really is this: 



Really. 



I am not running a second instance of prettymaps on the internet because 
that would be dumb. 

prettymaps.stamen.com http://prettymaps.stamen.com/ is still happily 
chugging away which is awesome and I don't imagine that will change any time 
soon. Maybe our confidence in Amazon's services and its 

longevity http : / /nymag . com/ news/ intelligencer/ amazon-2013-3/ , not to 

mention benevolence, as a company is just a kind of collective Stockholm 
Syndrome but, well... here we are. 

But that SD card has a working clone of prettymaps on it, complete with 
all the browser- crushing interactive bits and all the software needed to run it. I 
can simply plug it in to a Raspberry Pi and point a web browser at 
http : / /prettymaps . local and there it is. Which is kind of exciting. 

It's not a silver bullet. From an archival perspective lots of weak links 
remain. You still need the physical Raspberry Pi hardware. You still need ensure the 
physical integrity of the SD card itself (which is fancy talk for keeping multiple 
copies of it). You still need to ensure that the code itself will continue to run on 



contemporary web browsers. The Pi has a built-in web browser when you run it in 
GUI mode but I have not tested to see whether prettymaps makes it cry yet. If it 
does work then it more or less solves the viewing problem since all the software 
comes pre-baked with the archive itself. Oh, and also 

electricity http : / /www . aaronland . inf o/weblog/2 0 12/12/01 /cof f ee-and- 

wif i/#timepixeis . That, at least, is not a problem I am going to solve in the same 

margins of the day that I used to work on this project. 

But a thing that can be put to sleep and then asked to spring back to life 
— preserving its functionality — simply by plugging it in, at a cost of less than a 
hundred dollars feels like progress to me. And probably even less that that if you 
assume that any one Raspberry Pi can service multiple projects. 

I have not tried to get parallel- 

flickr http://straup.github.com/paraiiei-fiickr/ to run on a Raspberry Pi 
but that seems like an obvious next step. It is interesting to consider a pre-baked 
disk image that could be written on to a self-addressed and stamped SD card, so to 
speak, with a friendly web-based UI for people who aren't interested in sweating the 
technical sausage. There's nothing about the bare bones version of parallel- flickr 
that should be a problem so that's encouraging. The fancy parts of the parallel- flickr 
rely on the Java-based Solr https://iucene.apache.org/soir/ project which I 
have not tested yet. I know that Java will run on the Pi but it is also brutally slow. 
Maybe that is acceptable for the purpuses of a shallow-breathing but still living 
archive? 

Like I said, it feels like forward motion which is a nice way to start a 
Saturday morning. Especially when you're hungover. 



Some technical notes, for those of you who are in to that sort of thing: 

• Given that prettymaps is a web application it's just being served up by 
Apache. It could probably be done as easily and with a little less 
overhead by using nginx but I am not really worried about that. 

• Unlike the Si-backed scenario described above the archive is not 
serving up map tiles from a humongous bag of static files . One thing 
the Pi does not do is optimize the file system for use with something like 
the volume of files that prettymaps has. In other words you run out of 
inodes long before you've stored all your data on disk. I spent a little 
bit of time thinking about this and all the solutions involved a lot of 
low-level steps building and re-building the operating system from 
scratch and I did not have the stamina for that. Which means: 

• The archive is running a tile server. Specifically it is running 
TileStache (behind gunicorn which is in turn proxied through Apache) 
and serving tiles that have been squirted in to a collection of 
MBTiles http://mapbox.com/developers/mbtiles/ databases. 
Rather than write a custom TileStache provider to account for the fact 



that prettymaps requests tiles using static "safe disk cache " URLs 
instead of standard zoom/x/y tile server URLs I just added a flag to 
the site Javascript to do the right thing. Which means: 

• I've probably broken some cardinal rule of archiving by changing the 
code but I also signed and numbered — with a Mission 

Integer http://missionintegers.com/ of course — my own 
20x200 prettymaps print of San Francisco so I can claim precedence 
for this kind of bad behaviour. Or something like that. 

• I've always thought MBTiles was kind of a weird bird but it has proven 
to be lovely and wonderful for this project. The 3.8 million remaining 
inodes on my SD card send their thanks. 

• The . local part in the prettymaps local name is a function of running 
the avahi daemon for doing zeroconf broadcasting. I don't really know 
if that's the best solution but it was easy and enforces a degree of 
consistency in naming conventions. 

• / would love to get David Blackman's 

twofishes https://github.com/foursquare/twofishes geocoder 

running locally as a way to preserve the geocoding functionality. That 
looks like it might be a pretty involved process, though. Aside from the 
question of whether or not the Pi has enough "ooomph" to both load all 
the data and serve requests the build process itself requires installing a 
custom version of 

mongodb http://elsmorian.com/post/24395639198/building- 
mongodb-on-raspberry-pi . / had hopes that I might be able to get it 
all set up in the time it took to write this blog post but after reading that 
last link, it's a thing that will need to be saved for another day. 

Onwards. In my case, towards a sink full of dirty dishes. 
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you'll design thank us in the 

morning 

saving face 
The Measure of Success 



saving face 




Museums and the Web2013 http://mw2013.museumsandtheweb.com/ 

wrapped up a couple weeks ago. The Cooper-Hewitt won an 

award http://labs.cooperhewitt.org/2013/we-won-an-award/ for the work 
we've done on the collections 

website http : / /www . aaronland . inf o/weblog/20 12 / 1 1 /09 / jello/#parallel- 
tms this year, which was nice. I was also part of a panel about Humour as an 

Institutional Voice http: //mw2 0 13 .museumsandtheweb .com/proposals /humour- 

as-an-institutionai-voice/ . The panel was originally pitched by Erika 

Taylor http://erikataylor.squarespace.com/ who was not able to attend MW 

in the end, which is too bad because I was really looking forward to where she 
would take things. 

In the end, I asked a couple people from outside the museum world to join 

me. 



"Incumbents rarely produce 
great experience design. 
They don't have to, and they 
typically are dealing with 
historical monopolies on 
consumers or audiences." 

- httpy/cprhw.tt/x 



/ asked Heather Champ http : / /www . hchamp . com/ to join me to talk 
about the subject because aside from having thought about creating and nuturing 
community based projects for a long time and having been the public face ofFlickr 
she is also the person responsible for enshringing the words "Don't be 
creepy http://www.flickr.com/help/guidelines/ " in a legal document. 

Piotr Adamczyk https://sites.google.com/site/pdadamczyk/ is 

technically ex-still-sorta museum people having spent years at the 

Met https : //museumpipes .wordpress .com/ and is now managing the data side 

of things for the Google Art Project http: //www. googieartproject.com/ . The 

reason I asked Piotr is that I had the pleasure of seeing him 

speak http://www.flickr.com/photos/straup/8200155893/in/set- 

72157632078721181 at the National Digital Forum in New Zealand, last year, 

where he compared the Art Project to a Rachel Whiteread 

Sculpture http: //www. f lickr.com/search/ ?q=%22rachel%2 0whiteread%22 . 

Google, he said, "can show you the shape of the inside of your institution." 

Which is a fascinating way to think about what Google does and yet it is so 



rare that we ever hear big companies speak about themselves that way. Which is 
why I thought it would be good to have people from "business" on the panel to talk 
about the tensions of putting forward a public face. Piotr had to pull out just before 
the conference and Dan Hon http : / /www . danhon . com/ was gracious enough to 
fill in at the last minute. 

Over breakfast the morning of the panel, Dan described some of the work 
that they do at Wieden+Kennedy http : / /www . wk . com/ as helping organizations 
"form an opinion about themselves" which nicely sums up quite a lot of the issues 
latent in the panel's subject. Dan also wrote the quote above and, more recently, a 
proper good essay on the tyranny of digital advertising https : / /medium . com/ i- 
m-h-o/2bf a73373a9a . Most of the panel was a discussion between the three of us 
and the audience but I did a short talk to try and frame some of the issues around 
the idea of humour and institutional voice. 

The talk itself is a re-telling and a stretching-out of a duet that 
Seb http://www.sebchan.com/ and I did in March at the ArtsTech 

Meetlip http : / /www. artstechmeetup . com/2013/03/27/photos-recap-f rom- 
march-25th-meetup-wixlounge/ in New York City. 

At the time that we were putting together the slides for that talk I imagined 
somehow working in a piece I had just written about digital public spaces and 
measures of 

Success https : //s3 . amazonaws . com/f . cl . ly /items/ 153c3F0hld0al 909 3u3J/DPS .] 

for the Future Everything http://futureeverything.org/ conference in 
Manchester. I still think about doing that some day and it's still better that I've not 
tried but I've included the full text of that essay 

below http: //www. aaronland. inf o/weblog/2013/05/05/design- 

thanking/#measure if you're interested. 



This is what I said, instead: 




If you can tell us what Security Cat is saying we might let you in 




I'd like to start with a quote that was highlighted by John 
Allspaw http://www.kitchensoap.com/ , who is the head of operations at Etsy, 
from a book about safety and human factors by Sydney 

Dekker https://kindle.amazon.com/post/DmXW_3UBRzS5v7SaGkhpJA : 



Progress on safety coincides with learning from failure. This makes 
punishment and learning two mutually exclusive activities: 
Organizations can either learn from an accident or punish the individuals 
involved in it, but hardly do both at the same time. The reason is that 
punishment of individuals can protect false beliefs about basically safe 
systems, where humans are the least reliable components. Learning 
challenges and potentially changes the belief about what creates safety. 
Moreover, punishment emphasizes that failures are deviant, that they do 
not naturally belong in the organization. 



Hold on to that idea for the rest of the talk. I will return to it at the end but, 
for now, I'm going to start by talking about the Cooper-Hewitt collections 



website http://coiiection.cooperhewitt.org/ and use it as a kind of prism to 
talk about the idea humour and institutional voice. The collections website was re- 
launched in September http://iabs.cooperhewitt.org/2012/09/ 2012 and is 
meant to be tangible evidence of the 

direction http://iabs.cooperhewitt.org/2012/iost-coiiection-aipha/ the 
museum as a whole is heading in. 



The Cooper-Hewitt gets mentioned a lot these days whenever the subject of 
institutional voice comes up because of stuff like Security 

Cat https://twitter.com/VAJIAJIA/status/316349158720159744 . Because I 
think there is the sense that we are getting away with something that other 
institutions aren't or can't or won't. 

Honestly, I don't think we're "getting away" with anything because I don't 
think we're doing anything particularly subversive or even unusual. I also don't 
really want to talk about humour, at least not the funny-ha-ha kind. Or rather I think 
that when we're talking about humour we're really talking about something much 
larger that everyone senses is out there happening but which we haven't found a 
good way to talk about yet. 
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JL OBJECT OF THE DAY 




http^/cprhw.tt/3 

Cal Memes of Antiquity 



For example, this http://www.cooperhewitt.org/object-of-the- 
day/2013/04/ii/cat-memes-antiquity . We have about two hundred thousand 
objects in the collection, of which 127, 000 are publicly available online. Of those 
only about 18, 000 have been both digitized and been cleared for image rights. This 
is one of them. 



SRSLY. http : / /www. seriously amazing . com/ 




That leaves just under a hundred thousand objects without images. Some of 
those have descriptions with aren't narrative descriptions the way most vistors 
would expect. The descriptions we've got are basically way-finding tools. They 
identify enough of the qualities about an object so that you might find it in the 
archival stacks. 

For those objects without images but with a description possible we use 
some code magic to fill in the area normally reserved for a photo with the 
description associated with that object. Sometimes we end up with stuff like this. 
But as strange as this text is it's actually really important because it's often the only 
meaningful metadata we have about an object. 



National Design Triennial: Why Design Now? 




We only recently added the ability to view "list" results with thumbnails 
precisely because so many of the objects online don't have images. This is true of 
most museums and historically it's an interface problem that has been solved by 
displaying page after page of "image not available" clip-art icons. 

It is an interface solution that can only generously be described as shit. 

Not least because everyone always seems to choose a old-skool film reel 
waiting to be spooled on to a projector because, you know, that's a kind of imagery 
that really has anything to do with our collections. We didn't want to do that and 
held off long enough to have a think about it while we did everything else. 

This is the icon for an image that should be there because there's a record of 
the object having been digitized but, uh... we can't find it. That's not supposed to 
happen but it does and I think it's important to call that out. It's important that we 
see it and know that other people are seeing it too. 



It's also not the same as all the other images that have not been digitized yet 
which is what this pixelated box icon represents. Obfuscating those differences 
doesn't do our collections any favours. 




When we finally added thumbnail views we launched it with distinct "file 
not found" and the "image not digitized" icons. But there's also a necessary third 
icon that no one in the museum world ever seems eager to talk about: An icon for 
images that have been digitized but that can't be shown because they haven't been 
licensed or some equally insane restriction. 



NO SOUP FOR YOU 




That's what the "talk to the hand" icon represents. Because this is all people 
see. So maybe we can't show you the image but we can show you that we can't 
show you the image. 




Part of this is an exercise to develop a visual language to allow visitors to 
browse or scan the collection and to help make sense, even if it's just shades of grey, 
of the gaps in our collection. It's also developing a sensibility about how we 
approach the language we use to discuss the collection. To quote Erika Hall, from a 
presentation she did in 2008: Copy is 

interface, http: //www. slideshare.net/mulegirl/copy-as-interf ace 




It's an interaction model that tries to account for the shift from the 
exhibition being the principle the unit of currency for an institution to the 
entire collection being that measure. That's not a shift that I think everyone has 
acknowledged or is necessarily happy about but it's hard to deny that it's happening. 
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We also have an experimental mode for making sense of objects lacking 
images. It's called "Albers mode" or "Albers 

boxes" http://labs.cooperhewitt.org/2013/albers-boxes/ after the artist 

Joseph Alber's work on the interaction of 

Colour http://www.flickr.com/photos/straup/2611150655/ . 

We are borrowing a trick http : / /biog . doppir . com/ 2007/10/23 / in- 
rainbows/ that the social travel website Doppir developed: Each ring in these 
square represents a different property associated with an object. The outer ring of an 
Albers box represents the department that an object belongs to; the middle ring 
represents the period that an object is part of; the inner ring denotes the type of 
object. Each property is then used to generate a unique colour for its correspinding 
ring. 
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Ayse Birsel, 


s "Designer" 


http://cprhw.tt/9 









These six objects are all from the same department and period but there are 
four different types of things. Albers boxes might seem a bit confusing to people at 
first but we also think that their value and use will become apparent over time. 

Again, we are trying to find a way through the problem of developing a 
shorthand - a language - by which people can explore the collection in the absence 
of pristine records. 
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About a month ago we added the ability to search the collection by 

Colour http: //labs .cooperhewitt.org/2013/giv-do/ . Aside from being a fun 

way to discover objects it means we can also find new ways to talk about - or at 
least around - objects that are trapped in the soup of image rights. 



Who's on first 




Which is important because no one outside of the business cares about 
those details. They just think we look stupid for not having pictures of the things 
we tell them are important enough to hold and to cherish as part of our shared 
cultural heritage. 



It's important to remember that we - and I mean all of us in the business - 
have gotten as far as we have on the back of all this crap data. We have 
accomplished some pretty remarkable stuff and we are not morons. At the same 
time all of this highlights the fact that in the aggregate there is still very real data in 
an otherwise incomplete record. 

I would actually argue that the aggregate in all its incompleteness is more 
valuable than a finite set of perfect records. The aggregate provides larger surface 
area for people to understand and explore our collection and that is important. It 
also means that as each record is completed the value of the whole grows not-quite 
exponentially but exponentially-enough. 

It's also important to understand that everything I've shown you today has 
been built incrementally and not as part of a master-plan. We did not actively set out 
to show you the colours of the objects whose image rights we are still sorting out 
but that turned out to be a happy coincedence; the by-product of otherwise unrelated 
work. 



What we have done is to try and foster an internal environment, both 



technically and socially, that allows us do something tangible when those 
opportunities present themselves. To be able to move quickly because "museum- 
time" is a farce that we indulge ourselves in and one we can no longer afford (and 
an entirely other talk). 

Sometimes it is barely even a step forward but it is still forward motion. 



1292.0 - Australian and New Zealand Standard Industrial Classification (ANZSIC), 2006 (Revision 1.0) 




Division A AGRICULTURE, FORESTRY AND FISHING 

FISHING. HUNTING AND TRAPPING 
Group (Ml FISHING 
Class 0412 Prawn Fishing 



i in catching prawns from oc 



Primary acllvltias 



government club 


sss 0203 Onshore Aquaojltiire; 
lass 3604 Fish and Seafood 









So like I said at the beginning of this talk the Cooper-Hewitt gets called out 
for being playful, for giving a voice to our collection that is not normally seen in the 
museum sector. Honestly, I don't really know why this is such a big deal. Is it 
because we, and by we I mean the sector, have mistaken the trappings and rituals of 
so-called serious discourse for intent and the work itself? 

I don't know but I do know that it's happening elsewhere. For example, this 
is the website for the Australian Census 

Bureau http : //www.censusdata. abs . gov. au/censusservices/getproduct/cens 



f2011 Census 
82011 Census 

Throw another shrimp on the barbie! Census 
data reveals there are 445 people employed 
in Australia's Prawn Fishing industry. 

^ Reply Retweet 1f Favorite ••• More 

RETWEETS 



"playful" 



And this is the Australian Census Bureau's Twitter 
account https://twitter.com/201icensus . 

It's clear that they are trying to craft a narrative around what they are doing 
with a goal and a motive: To get Australians to register with the census. I also 
choose to believe that this is more than just a careful brand or social media 
"strategy". 

What this tells me is there is an honest and genuine delight that the people 
who are charged with compiling all these statistics find in their work and they have 
been given the license - the freedom - to celebrate it. 



2011 Census 

02011 Census 



X- ST Follow 



You've got a face for radio! Census data 
reveals there are 532 people working in the 
Paper Bag Manufacturing Industry. 

Reply Retweet ^ Favorite ••• More 
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"institutional voice" 



This is the so-called faceless bureaucratic face of government talking. 
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Outdoor Public Warning System (OPWS) Siren 
Information 



ACS Resources Exams and Training Contact ACS Relate] Li 



What Is the OPWS (or? 

The City's Outdoor Public Warning System is designed 
emergency announcements can be broadcast ever any 
throughout all neighborhoods In San Francisco. Treasui 

Why do the sirens go off every Tuesday? 



n at another time? 



Turn on (he radio or tain 



STAY CALM 



You also see people taking matters in to their own hands. For example, the 
city of San Francisco has one of those emergency 

sirens http: //sfdem.org/index.aspx?page=55 you can hear for miles around. 
Every Tuesday they test the thing and if it ever sounds off-schedule people get 
genuinely upset and concerned. 



This is the city's official webpage for the siren. 




This is @SFSiren Twitter account http://www.twitter.com/sfsiren 
which, as far as I know, is not maintained by the city. That someone has bothered to 
create this and maintain it is telling. 




This is Little Printer http://bergcloud.com/littleprinter/ from 
BERG, a design studio in London. 

It's a printer. It's a little one. It's not only designed to be a kind of network- 
enabled letter box that is connected to the Internet printing regularly scheduled 
publications but to be an active (and polite) part of your day-to-day life. Its hair 
grows over time. It smiles at you. It stops smiling if it hasn't printed anything in a 
while. 

I actually find some of these cues more annoying than not but that's a 
personal bias. What I think it is interesting about Little Printer is that it is designed 
— from the start — around those properties and characteristics that we are seeing 
people invest in objects. It is meant to be a social creature, part of your life and not 
simply an object that reacts to the mundane triggers of life. 




Little Printer also has an API which means that I can write myself an upload- 
by-email program and email photos to M. back in New York. So I sent her this 
photo of Heather while we were having breakfast the other day. I could have sent 
her a text message with a photo attached but there's something lovely about the idea 
that the sound of Little Printer spinning up (it sounds a bit like a fat snoring cat 
when its printing) would catch M.'s attention and she would watch as the paper 
spooled out wondering whether there was a new photograph. 

I know that you know that I know and that ability to hold hands at a distance 
is part of the fun. That's a pretty simple kind of shared anticipation but so are most 
social moments. So is most play. 





http://cprhw. 
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The Cooper-Hewitt launched a Little Printer 

publication http://remote.bergcloud.com/publications/lll last week. It's 
sent out every week and invites users to draw the descriptive text for objects that 
haven't been digitized yet. 
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Remember the "sea horse with the enormously long sea body" ? 



We don't have an image of it so why not ask our visitors to draw one. Given 
the amount of metadata we have or don't have many of the objects in our collection, 
including this one, are essentially conceptual pieces. They are entirely intellectual 
experiences, especially when you consider that the written descriptions are 
deliberately void of narrative. 



If celebrating the often absurd reality of some of our objects by asking 
people to imagine what they might look like is what it takes to give people even just 
a toe-hold in to our collection then I see no problem indulging them in a bit of 
speculative fun. None at all. It is through projects like this that we might start to 
assert a communal proof — with an emphasis on community since we are the 
Smithsonian and have a mandate that extends beyond the museum's walls — that 
these objects actually exist. 



We haven't gotten a drawing of the sea horse yet. 




But we have gotten 

this! http://www.flickr.com/photos/phobia/8654686720/ I mentioned the 

descriptions for our object records are essentially a way-finding device. They were 
the photographs before museums had cameras, the databases before we had 
computers so I will leave as an exercise to the viewer to decide whether this 
drawing or it the description that spawned it would better help you find the original 
object in the stacks. 



It's more than just being playful, though. It's really about being welcoming. 
That may seem like hair-splitting but I think it's an important distinction. 
Welcoming means a few things. In our case it means understanding that many of the 
people who visit our collection don't live and breathe the gorey details of captial-D 
design let alone an historic decorative arts collection. But that does not mean they 
are unequipped to deal with it. 

They are just busy enough being awesome in other field of study that they 
haven't had the time to learn our shop-talk. They are more than capable of 
understanding what's going on only if we stopped talking to them in codespeak of 
professional anxiety and stopped expecting them to think that nonsense like 
International Art 

English http : / /canopycanopy canopy . com/ 1 6 /international_art_english 

(sic) is some kind of proxy or signal for knowledge. 

This is a photo taken by someone who works for the UK government, 
specifically the Government Digital 

Services http://digital.cabinetoffice.gov.uk/ (GDS) team. It's a sheet of 
paper with a hole cut out of the center taped to the window of their offices. It is a 



healthy reminder we could probably all use from time to time: That we are afforded 
the luxury of our jobs by our peers. Not our professional peers but all those people 
we live with every day. That we are given positions of trust and the public good by 
those people because we, as a society, believe they are vaulable and important. 

GDS are also doing, hands down, the best work on the Internet right now. 



Government Digital Service 

Design Principles 

Listed below are our design principles and examples of how we've used them so far. These build 
on, and add to, our original 7 digital principles . 

I Start with needs" 
Do less 

3 Design with data 

4 Do the hard work to make it simple 

5 Iterate. Then iterate again. 

6 Build for inclusion 
Understand context 

B Build digital services, not websites 

9 Be consistent, not uniform 

1 0 Make things open: it makes 



http://cprhw.tt/8 



GDS is tasked with reducing government costs by not simply migrating 
services online but in their ways by making those services so good that people will 
prefer "digitial by default". And these are very real services — taxes, health 
information, business requirements — with very real consequences. 

This is not about tailoring a flashy government experience but about 
speaking with a language by and for the people the government serves, which is 
absolutely not the same as pandering to the lowest common denominator. The 
websites that GDS are building are, by-and-large, entirely absent of images. These 
are websites that, almost literally, speak to users and as such GDS has been 
publishing a series of guiding principles for the work they do. 



I think the ninth principle "to be consistent, not uniform" is especially 
important. This is what the detailed description says: 



Be consistent, not uniform 

Wherever possible we should use the same language and 
the same design patterns — this helps people get familiar 
with our services. But, when this isn't possible, we should 
make sure our underlying approach is consistent. So our 
users will have a reasonable chance of guessing what 
they're supposed to do. 

This isn't a straitjacket or a rule book. We can't build great services by rote. 
We can't imagine every scenario and write rules for it. Every circumstance is 
different and should be addressed on its own terms. What unites things, 
~ 1J ' 1 ^ ^ ' ' ne that users will hopefully 

e into new digital spaces. 



http://cprhw.tt/j 



Like the Australian Census Bureau, this is the government talking. This is 
voice of capital- A authority speaking. Russell Davies has written a really good 
piece about the work GDS is 

doing http: //russelldavies . typepad. com/planning/2013/04/the-unit-of- 

deiivery.html in which he says that "The Product Is The Service Is The 
Marketing" which is a useful way to think about institutional voice. 




Being welcoming means being willing to be open and honest about one's 
own uncertainties and trusting that those same visitors are capable of understanding 
that sometimes we are still actively working through a problem. Most importantly it 
demonstrates that there are signs of life. 

Because it's not all funny-haha all the time. The work that people do around 
collections is genuinely serious but it's also not always complete or even correct but 
it's still worth talking about. That sometimes the discourse of failure is more 
interesting than triumphal certainties of staying "on-message". That not all failures 
are the same or have the same consequence. 



This is a Seriously Amazing 404 page 



IZUMAH OBJECT? 



institutional wabi sabi 



We have to find ways to allow ourselves to speak about this stuff. And I 
wonder if that's why we get so excited and so focused on the idea of humour. When 
Seb Chan talks about the work we're doing at the Cooper-Hewitt he often talks 
about the idea of institutional wabi 

Sabi http: //www. freshandnew.org/2013/04/institutional-wabi-sabi/ . He 

says: 



Wabi-sabi is a challenging concept for Westerners raised on a diet of 
Modernism. It celebrates impermanence, imperfection, and 
incompleteness. It celebrates the small and the intimate. It is the rough 
hewn bowl, not angular refined box. 

Importantly, though, it is not an excuse for incompetence. 

Consider how your museum could be a bowl, rather than a box. A 
tumble of objects rather than a grid. What might this mean for your 
institutional design aesthetic? Is it a return to the densely cluttered 
cabinet of curiosities? The dusty attic or antique shop? What might that 
mean for the 'approachability' of your institution? And what of our long 
desired aim of serendipitous discovery in our online databases? 



Seb also talks about the work we're doing at the Cooper-Hewitt as a strategy 
of accelerating towards failure as a way of nurturing a confidence both in what 
you're doing and the ability to correct when things don't work and adapt to change. 



To be serious enough in the motivations around the work that it has a mass 
and a presence but not heavy as to be an immovable lump. So when we talk about 
the measure of success we are often really talking about the measure of failure. And 
the confidence to do both. Thank you. 




2013-05-05 



The Measure of Success 



Earlier this year I was ask to write a short piece about digital public 

Spaces https : //s3 . amazonaws . com/f . cl . ly /items/ 153c3F0hld0al9093u3 J/DPS . 

for the Future Everything http://futureeverything.org/ conference in 
Manchester. This is the long version that I sent the organizers before we eventually 
agreed on the short version. 

In 201 1 I was invited to speak at the Experimenta Design Biennale in Lison, 
Portugal. In the mornings panel discussions were held and the audience was 
encouraged to ask questions of the speakers. On the last day of the event I asked a 
question to a group of product designers and as I was sitting down realized that I 
had meant to ask a very different question. What I asked was: 

"Would you (as product designers) discuss what you imagine the impact of 
just-in-time production facilities and on-demand manufacturing will have on the 
profession?" 

It is not a world that has arrived yet but everyone can see the dust clouds on 
the horizon and print-on-demand is a kind of leading indicator or at least proof that 
it's not all aspirational hand-waving. The question was deliberately open-ended 
because I was more interested in the discussion than in any one point of view. 



What I meant to ask was: 

"Would you (as product designers) talk about what you imagine the impact 
of just- in-time production facilities and on-demand manufacturing having on your 
_idea of success_ as professionals?" 

Experimenta has a heavy focus on product design, whose minutiae and 
sausage-making, was still a relatively new world to me but I had become aware that 
over the course of the event I was hearing an awful lot of comments like: 

• "It was ahead of its time . " 

• "People weren 't ready for it. " 

• "/ had 90, 000 of them manufactured and then had to figure out where 
to store them." 

• '7 went bankrupt. " 

And it occurred to me that in recent memory the notion of success for 
product designers has, by-and-large, been a binary one: Either you had produced 
and sold four-million chairs (so to speak) and were considered a god among men or 
you were, basically, less than dirt without many shades of grey in-between. And 
right or wrong this has largely been a function of the cost and access to the means of 
production. 

Building and tooling, and re-tooling, a factory remains a non- trivial and 
expensive endeavour and, generally, in order for everyone to recoup their costs it 
means that whatever is being produced needs to be sold at a premium or aspire 
towards "blockbuster" status in order to eventually offset a sale price that doesn't 
reflect its true cost. And so we tend to celebrate those who can guarantee a return on 
investment. 



Which is fine. Mass-production is still a novelty in historical terms and 
despite continued growing pains it has afforded us a world that most people take for 



granted now and would quickly pine for in its absence. And there is nothing de facto 
wrong with aspiring to, and having the _opportunity_ to, create a "blockbuster" 
product whose success is celebrated far and wide. 

But that is not the only measure of success or, at least, it shouldn't be. 
Technologies like 3D printing are just as interesting for the material products they 
create as they are for the ways in which they might alter the prism through which 
we see our relationships to one another. 

I do not expect that we will all own and operate person CNC machines in the 
basements of our homes, any time soon. I do, however, believe that in time there 
will be a variety of small and large scale commercial operations in dense urban 
environments, and corresponding numbers in rural areas, whose services people 
might contract to produce bespoke and high-quality objects. 

And what will that mean for product designers? What will it mean for 
product designers to achieve financial success (or at least stability) producing and 
selling items in small batches and to be able to weather the financial cost of a failed 
or avant-garde product? What will it mean for product designers to do all of this in 
the absence of mass approval and celebration? 

Increasingly we are no longer able to use access to the means of production 
and, in the case of the internet, distribution as a proxy for either quality or authority 
or ultimately to recognize success. 

Which is not to suggest the end of quality or authority but only to point out 
that the ruler we've used in the past is no longer adequate. An important measure of 
confidence in our ability to judge things has gotten completely messed up and we 
are still trying to find new bearings. On top of it all it is a measure most people will 
never willingly let us use again. 

For example, why didn't the business man David Walsh give his extensive 
and wide-ranging art collection to an established museum but instead built his own 
- the Museum of Old and New Art (MONA) in Hobart, Tasmania - from scratch? 
Again, the answer is less interesting than the question. MONA is the far end of the 



spectrum when we talk about what's possible. By all reports David Walsh has more 
money than the sky but squint your eyes a bit and you see not money but means and 
desire. 

A desire that has always been present in people but often without an outlet. 
Without the means. Now look at the internet. 

Because that is the ocean that museums and archives and libraries are 
swimming in today. The internet is the means that people - average citizens and 
well-informed amateurs - are using to greater and greater effect to perform the roles 
that the cultural heritage sector (some might say "industry") has traditionally 
assumed. 

The subject matter of the things being collected and discussed may, on the 
surface, seem to undermine that argument. For example, a comprehensive 
cataloging of images of VGA 

dongles http://iabs.cooperhewitt.org/2013/thinking-dongies/ does not an 
archive, or an expert or a scholar, make but it is a pretty important piece of the 
puzzle. And what happens when that random person with a weblog or a Tumblr 
account writes — and then posts — the most comprehensive history of VGA 
dongles the world has ever seen? Everyone remembers the epic 9, 000 word Quora 
post On airplane cockpits http://www.quora.com/Airplanes/What-do-all-the- 
controls-in-an-airplane-cockpit-do , right? Call me naive but I thought that 
we had decided that what was important was measuring people on the rigour and 
merit of their study and not so much on the subject themselves. 

Just as important is the idea that mere inclusion in a catalog automatically 
confers merit to a subject. When catalogs were synonymous with "books" this made 
a certain kind of sense if only to reflect the very real cost of compiling and 
producing and shipping and finally housing the end product, not unlike traditional 
product design. That measure no longer makes much sense in a world of databases 
connected to a global network and risks blinding us to the opportunities that the 
present and the near-future yield. 

Consider this recent posting by the Orange County Library, in Florida, for a 



request for proposals to develop a software system to collect and catalog 
obituaries http://jobs.code4iib.org/job/6504/ submitted by the public: 



The EPOCH (Electronically Preserving Obituaries as Cultural Heritage) 
project will provide a service to the community, in that it will serve as a 
depository of information that will be held for future generations of 
researchers and genealogists. Family and friends of the deceased can 
submit detailed obituaries as a tribute to their loved ones, and in doing 
so help build a meaningful history of the residents of the community. 
With the ability to upload photos, videos and other items, a 
multidimensional portrait of an individual and their contributions to the 
community will be created. 



The opportunity that museums and archives and libraries have - both as 
separate institutions but also together as the distinctions between them continue to 
blur in a world becoming digital - is to act as a zone of safe-keeping, as a place to 
preserve the present for some future as-yet unknown interest or understanding; for 
all that "stuff" we've simply never had the means to collect. 

Facebook is by any measure the world's largest repository of wedding photos 
which in the moment amount to little import and even less interest. But come 50 
years from now they will, in their aggregate, be a "special collection" by any other 
name; a wealth of hints and cues and emergent pattern about the times in which they 
were taken. They are the raw material of future scholarship. They are also locked 
away inside a commercial enterprise with little or no obligation to anyone other than 
their shareholders. 

The cultural heritage sector is more than the sum of its scholarly 
publications. It is a public trust made possible by our peers - the community of 
strangers, not our professional colleagues, with whom we share our short lives - 
because it is seen as a common good. With that trust comes not only the question of 
access but increasingly an expectation of inclusion and participation. It's not entirely 
clear to anyone, I think, what that means but if we, as a community, don't stop to 
consider it we may find that people simply take on the project themselves. 



Because they can. 



2013-05-50 



verb impostors 



Quantified Selfies 



Quantified Selfies 




quantified selfies 



/ had the privilege of attending and speaking at the National Digital 
Information Infrastructure and Preservation Program 's Digital Preservation 

2013 http : / /www. digitalpreservation . gov/meetings/ndiippl3 . html 

conference yesterday. I was asked to be part of a panel discussing "Innovative 
Approaches to Digital Stewardship" and I gave a very different talk than I might 
have given two months ago, but life is sometimes an 800-pound gorilla that way. I 
did not set out to write "part 3" of the New Aesthetic http : //new- 
aesthetic . tumbir . com/ talks but if I had it probably would have looked 
something like this. I, at least, can see the sweater threads that connect them. Parts 

One http : //www. aaronland. inf o/weblog/2 0 12/03 / 13 /godhelpus/#sxaesthetic 
and two http: //www. aaronland. inf o/weblog/2 012/ 10/08 /signs /#stories are 

both available online if you're curious. This is what I said: 



I'm going to start with a quote by Umberto Eco, from a piece he wrote 
shortly after the WikiLeaks cables were 

released http://www.presseurop.eu/en/content/article/414871-not-such- 
wicked-leaks : 



I once had occasion to observe that technology now advances crabwise, 
i.e. backwards. A century after the wireless telegraph revolutionised 
communications, the Internet has re-established a telegraph that runs on 
(telephone) wires. (Analog) video cassettes enabled film buffs to peruse 
a movie frame by frame, by fast-forwarding and rewinding to lay bare 
all the secrets of the editing process, but (digital) CDs now only allow us 
quantum leaps from one chapter to another. High-speed trains take us 
from Rome to Milan in three hours, but flying there, if you include 
transfers to and from the airports, takes three and a half hours. So it 
wouldn't be extraordinary if politics and communications 
technologies were to revert to the horse-drawn carriage. 



This is not a talk about WikiLeaks but hold on to his words and treat them as 
a kind of soundtrack music for the rest of this presentation. 




Hi, my name is Aaron. I am not a trained museum professional. I am not 
even a trained computer programmer. If anything I studied painting but I am mostly 
part of that generation for whom everything changed, and who dropped everything 
they were previously doing, when the web came along. These days I am the Head of 
Internet Typing at the Smithsonian Cooper-Hewitt National Design Museum. 

We are part of the Smithsonian. We are not in Washington like the other 
Smithsonian museums. Instead we are located on the Upper East Side of Manhattan 
in Andrew Carnegie's old mansion. The Cooper-Hewitt became part of the 
Smithsonian in the late 1960s and our history is the collection amassed by the 
Hewitt sisters with a strong emphasis on the decorative arts. In the 90s we took on 
the mantle of being a national design museum and we've been working through 
everything that means since then, particularly in a world where design is becoming 
increasingly intangible. 

We are closed until 2014 and are renovating the physical space as well as the 
digital infrastructure that increasingly holds it all together and a big part of my time 
is spent helping to imagine what it means for the Cooper-Hewitt to be native to the 
Internet and the rest is spent figuring out how to build it. 



I am going to talk around the work we're doing at the Cooper-Hewitt rather 
than about the specifics, today. Rather I am going to talk more broadly about the 
kind of continuous partial event horizon we are all operating in these days to try and 
better articulate a rationale - also a kind of soundtrack music - for "why" we are 
doing the things we are because we are still feeling our way through the "how". 




This is my new favourite Twitter 
account, https : / /twitter . com/darpaatiasrobot It's an account that someone 
set up for a 300 pound bi-pedal robot called ATLAS courtesy the smart people at 
Boston Dynamics. Looking at it one can only imagine what it will end up being 
used for but it's being still promoted as a tool for humanitarian crises and disaster 
relief scenarios. 

Either way it's worth considering that given the cost of storage these days 
one of these robots could come pre-loaded with all of human knowledge on them 
which is interesting because I like to imagine them walking the Earth retelling our 
histories to strangers over camp fires. 

And if we start to imagine that robots like these are "people" or "people 
enough" what do they see? Even if we understand that they don't really see anything 
when do we care enough about the history of their observations that we forgive 
them their lack of awareness the same way that a design museum forgives an object 
that no longer works and collect it anyway? 




This is my still favourite Twitter 

account, https : //twitter . com/ self awareroomba 



I show this slide a lot, first, because we actually have a Roomba in our 
collection and, second, because things like this Twitter account are what it means to 
be a museum in 2013. 

It is most definitely not about Twitter. Twitter is important because its the 
easiest, dumbest tool available to people but its still just the delivery mechanism. It's 
about the fact that some random person out there on the Internet is building a record 
of understanding about Roombas that may well rival anything we will ever do 
ourselves. 



Beyond that, we are being forced to accept the fact that our collections are 
becoming "alive". Or at least they are assuming the plausible illusion of being alive. 
We are having to deal with the fact that someone else might be breathing life in to 
our collections for us or, frankly, despite us. We are having to deal with the fact that 
it might not even be a person doing it. 



We are watching as the world around us creates communal proofs of our 
collections. 



That idea of a communal proof is something I talk a lot about at the museum. 

We have about 217 thousand objects in our collection and currently 123 
thousand of them are publicly viewable. Of those that are public only about one- 
fifth of those objects have been digitized and quite a lot of the metadata we've 
collected can only charitably be described as poor. 

This is okay. Or rather, it can only get better from here. More importantly by 
standing these records up in public we take the first baby-steps towards lending 
them enough weight and mass in the universe that other things might orbit them. 

In the absence of our ability or willingness to let people roam our storage 
facilities we want to replace the blind faith that currently defines the existence of 
things in our collection with something a little more concrete. We want people to 
feel confident enough to bother sharing in their reality. The digital proxies are still 
just that. They don't replace the objects but they enable two people to point to and to 
share the same URL and in doing so make tangible that which is otherwise so 
invisible that it might as be a purely conceptual device. 




That ability to create, to participate in, communal proofs is I think one of the 
reasons we saw the rise of "social media". Social media is just buzzword bingo for a 
deep vein that has always been present throughout history: We all want to leave 
traces of our lives — proofs — and that's something which found, in the Internet 
and the communications technologies of the last decade, the necessary conditions to 
blossom in a way that had never been possible before. Maybe the only way to truly 
leave a mark on history is through violent conquest or by erecting a 700-storey 
building or by carving your face in to the side of a mountain but I think Internet 
culture demonstrates that there's a real and profound desire to imagine a different 
way. 

Which is great but, as many others have pointed out already, there's suddenly 
orders of magnitude more stuff that we feel the burden to collect and archive and 
preserve. For the last couple of years I've been working on a project called Parallel 
Flickr, which is a meant to be an archive, a shadow copy, of all the photos I've 
uploaded to Flickr as well as those that I've favourited. 

I tend to focus on Flickr because I am scarred by the years I worked there 
but it's best to think of "Flickr" only as a reference implementation. Replace it with 



Facebook or Twitter or any other community that people have rallied around and 
most of the issues are the same. Parallel Flickr is an attempt to work through a 
number of questions, in actual code, including: 

• What is the representative sample of something as big as Flickr, 
something so big you can't even see its edges? I happen to think there 
isn't one. 

• Personal archiving in general and, as Anne 

Wooton https : / /twitter . com/annewootton mentioned yesterday, 
trying to understand the roles and responsibilities that individuals have 
in preserving their online presences. 

• Creating a living breathing archive that is not just an inert bag of files. 

I realize that not everyone agrees with me on this but we are fast 
approaching a time when the expectation for most people is that preservation and 
access and just as importantly some degree of functionality are the same thing. Or 
rather, that any one of those things without the others is a kind of shit. Consider the 
way most people confuse the Internet Archive and the Wayback Machine or the 
stunned disbelief when people find out there's no way to access the Library of 
Congress' Twitter archive. 



But there's also a fourth thing which in many ways is really what this talk is 

about: 

How do we preserve the interactions that a service like Flickr affords its 
users? Which is a kind of fancy talk for "relationships" which is itself fancy talk for 
"permissions". Flickr, and sites like it, succeed precisely because although they 
may actively encourage sharing-by-default they don't require it. That is 
something we need to be mindful of when we think about preservation. 

Replace "permissions" with image rights or rights holders, if you're talking 
about written correspondence, and then multiply that by the scale of something like 
Flickr and take a deep breath. Because although social software is not specifically a 
"rights" question the quicksand is the same. 

Parallel Flickr does not solve this problem but tries to chip away at it by 
using the Flickr API itself to validate users. Without getting in to the boring 
technical details think of it as like logging in to Parallel Flickr using the Flickr 
equivalent of Facebook Connect. 



One of the benefits of this approach is that I can also use the API to retrieve 
my contacts and relationships from Flickr. That means if you visit Parallel Flickr 
and are logged out you only see public photos, but if you've logged in and we have a 
relationship you can see private or semi-private photos. Like I said, it's not a perfect 
solution and relies on Flickr being always-on but it's a start. It's certainly better than 
having to wipe those photos from the face of the Earth which is what would happen 
in the absence of some kind of privacy controls. 



The reason I mention this is that as I've been doing this work I keep bumping 
up against the idea that maybe the future of archiving and preservation is going to 
involve a lot more running of services - things with moving pieces that need to be 
maintained and fine-tuned - than we've normally been used to. 

For example, what would it mean for the Library of Congress to run Parallel 
Flickr or something like it? What would it mean for the Library not simply archive 
its own photos (which, I'll grant you, would be a bit of a circular argument) but to 
find all the other users who've ever interacted with their photos and - as an opt-in - 
offer to archive their photos as well. What if you extended that offer to all the 
contacts of those people as well? 

It means that although the Library hasn't quite figured out how to archive all 
of Flickr it can start to capture the context, and the people, who have crossed paths 
with the Library's photos. It becomes an archive of all that which has intersected a 
point in history. 

But there's an important twist in this: That for as long as Flickr's login 
service can be considered reliable and trustworthy the Library pledges to honour the 



permissions model for those photos. If a photo can only be view by "friends and 
family" on Flickr, it can only be view by those same people on the Library's site. 
But the moment that confidence around identity is called in to question — because 
some hypothetical misfortune befalls Flickr — any photos that aren't already public 
go dark and the so-called 70-year clock kicks in. But then, at the end of those 70 
years all of those public resurface and are placed in to the public domain. 

There's a explicit contract here which is that the Library promises to preserve 
the permissions model in the present in exchange for a person gifting that present to 
the future. My hunch is that people would be lined up around the block to 
participate. 

Finally because Parallel Flickr goes out of its way to mirror both the ID and 
URL structure of Flickr itself if means that two separate instances can be easily 
merged in to a single larger instance. What that means is that two institutions can 
each tackle the problem of archiving something the size of Flickr in managable 
bites, separately and with an institutional focus, and merge their work as time and 
circumstances permit. It affords us a way to try and think through what it means to 
re-grow a network that big organically, and without having to contemplate 
swallowing the ocean. 




But then sometime around 2008 the then-and-current head of the NSA 
asked, reasonably enough it should be added, "Why can't we collect all the signals 
all the time?" and so now we have among many others like it the Utah Data 
Center http : / /www . openstreetmap . org/browse/way / 1 58898045 located just 
across the field from the Thanksgiving Point Butterfly Garden and Golf Club in 
Bluffdale Utah. This is, we're told, where all the signals will 

live http://www.wired.com/threatlevel/2012/03/ff_nsadatacenter/ . 

I mention this because it exposes a fairly uncomfortable new reality for those 
of us in the cultural heritage "business". That we are starting to share more in 
common with agencies like the NSA than anyone quite knows how to 
conceptualize. 



Bluffdale, it is claimed, will not simply preserve and archive all of the 
Internet - tapped at the source - but provide the facilities to index, query and replay 
the damn thing at will. This might be bluster or just plain-old 

FUD https : //en. wikipedia. org/wiki/Fear ,_uncertainty_and_doubt . Maybe 

it's true or maybe it's an aspirational half-truth or maybe it's just an epic design 

fiction http : / /nearf uturelaboratory . com/2 009 / 03 / 1 7 /design-f iction-a- 
short-essay-on-design-science-f act-and-f iction/ .We don't know. 

Maybe its some combination of the three but no matter how you slice it it 
sounds a lot like the kinds of missions and mandates that we claim as so-called 
"memory institutions". Just without the buffer of time. Once the sort of information 
and documentation being collected at places like Bluffdale is divorced from any 
immediate consequence it is typically lauded as a rich trove of capital-H history. 

Does this make Bluffdale the new National Mall? 

It also raises another more interesting question: How do we archive 
Bluffdale itself? Or, if there is nothing to archive since it is the archive then maybe 



it's time to throw in the towel and just let NS A itself run the whole affair? 



So, how did we get here? I think we're still trying to figure this out but I can 
point to a couple of likely suspects. 

The first is simply that consumer-grade technology leap-frogged the cultural 
heritage sector's ability to fund-raise and hire third-party contractors. That the NSA 
or any organization (see also: Google) is able to operate at this scale is impressive 
but it's not like they've made a jet pack. 

I don't want to belittle the technical chops that an organization like the NSA 
has at their disposal but what we're talking about in this situation is less a moon-shot 
advance in technology than it is being given the license and freedom to think this 
big. 



Which brings us to the second suspect: A legal and political framework 
referred to as Unitary Executive 

Theory https://en.wikipedia.org/wiki/Unitary executive theory . Unitary 

Executive Theory is part of the long-running debate about the separation of powers 
between the executive and legislative branch and it's a position that basically says: 
The legislature is fine however the executive can still do whatever it wants. 

Unitary Executive Theory is a position that was advanced by the Justice 
Department during the Reagan administration. And despite being largely trounced 
by the Supreme Court in the late 1980s many of those same lawyers found 
themselves working in the second Bush administration's Office of Legal Counsel in 
a post September 1 1th world. 

The OLC writes briefs for the President offering opinions about what may or 
may not be legal and their advice, during the first decade of the 21st century, seems 
largely to have consisted of saying that "What happens in Vegas stays in 

Vegas http://openlibrary.org/books/OL9771046M/Takeover ". 




Around the same time the laws regulating the number of years before which 
presidential papers must be released to the public were changed. The number of 
years was increased from twelve to seventy. 

The stated reason was to better foster an environment where the presidents 
advisors could feel confident giving "honest counsel" without having that blow back 
on their careers during their lifetime. I mention this only to point out that it's another 
example of the same dynamic around privacy that gets played out in social websites. 
Dick Cheney, when he was vice-president, is famously said to have eschewed using 
email at all precisely to leave no record. Remember Eco's horse-drawn carriage? 



danah boyd http : / /www . danah . org/ , a researcher at Microsoft and best 
known for her work with youth culture and the Internet, wrote an essay in 2011 
about privacy in a networked 

age http://www.danah.org/papers/talks/2011/PDF2011.html where she 

argues that: 



Privacy is a feeling that people have when they feel as though they have 
two important things: 1) control over their social situation: and 2) 
enough agency to assert control. 

She goes on to say: 



One of the reasons that I love working with teenagers is because, even 
though they have very limited agency, they still desperately crave it and 
try to find it in the cracks and folds of their lives. What this means is 
that they don't take control for granted. They assume that they have 
limited control over social situations because they're constantly having 
control taken away from them, most notably from their parents. 
Surveillance is a given in their worlds, something that more teens take 
for granted than not. They're not thinking about corporations or 
governments, but parents and teachers and friends. They're worried 
about social privacy, not data privacy, because violations of social 
privacy are very real to them. 



In Europe there are serious laws on the books to ensure people have a right 
to know what sort of data is being collected about them, at least by the private 
sector, but they do not have the right to be 

forgotten http://euobserver.com/news/i20650 by those companies and 
services. 




They lack agency to assert control. 




I used to joke that Facebook had become the world's largest honeypot at 
least before the US government apparently decided to (re) nationalize the 

Internet http : / /www . guardian . co . uk/technology / 2 013/jul/28 /edward- 
snowden-death-of-internet . According to Wikipedia, a "honeypot" is: 



[A] computer, data, or a network site that appears to be part of a 
network, but is actually isolated and monitored, and which seems to 
contain information or a resource of value to attackers. 



Which makes it all sound a bit dire but let's be honest about something: 
Long removed from the pain of the now, and it may take 1 or 2 or 10 generations, 
our future selves will thank the NSA - or Facebook if we can ever figure out how to 
get stuff out of it - for all the stuff they've been collecting. 

The NSA are betting on the future in, really, a pretty profoundly optimistic 

way. 




If you hold to a particularly wooly-eyed and tree-hugging world-view, as I 
do, that says we should be finding ways to give voice to the oppressed or the 
otherwise simply ignored and to write a history whose tapestry is richer than only 
the voices of the victors then it is difficult to deny that the Internet, and all the 
technology that we've built to support it, has done a better job of furthering that 
ideal than anything that has come before it. Maybe something better will come 
along in the future but we are not in the business of preserving future promises. 

Historically we have always equated the cost of inclusion with notability. 
The cost of being included in a physical book used to be the communal proof than 
someone or something was worth the trouble of producing that object. This just 
doesn't hold anymore in a world cheap and fast computing power. 

Electricity remains the single point of failure in all of this. Really. But that is 
probably also an event horizon that has been permanently lost to the past. If the 
power goes out we'll have much bigger problems on our hands. And so, perhaps we 
can look at the oft-cited "frictionless" nature of communication — all the LOL cats 
and all the selfies — not as a tragedy of the commons but as an opportunity to serve 
as a kind of zone of safe-keeping. To create a more communal proof and to give the 



present enough weight and mass in the universe that the future might choose to orbit 
it with greater confidence. Or at least empathy. 

To bet on the future, much as the NSA has begun to do, but actively and 
deliberately working to temper all the creepy bits. 




So maybe this is what I think the challenge is going forward: To debate and 
advance a rhetoric, a measure against which we might be judged and challenged, 
that aims not to deny the future but simply to protect the present from itself. 

We are in, and have been living in for a while now, one of those "between two bus 
stops" moments and while I don't have a ready answer to the problem I think we 
need to understand that it's real and that it's not going to go away on its own. 




Thank you. 



Then I went to see James' drone 

shadow http: //www. vanity f air . com/culture /2 013/ 0 6 /new-aesthetic- james- 

bridie-dronessiideshowiastsiide _5 and somewhere in all of this the CIA 
managed to "acquire" Osama Bin Landen's assault rifle and put it on 
exhibition http: //rt.com/usa/cia-bin-laden-ak47- 
593/#.ufGQcicczBk. twitter . Fm just saying... 
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I am one of the six or seven people left in the world who write and maintain 
their own blogging software. Way back in 2005 I rewrote the toolchain that 
produces this weblog. It was not the first time. I did this for a few reasons. By that 
time I had tried almost every hair-brained scheme under the sun for generating a 
dynamic site and watched as they all failed and ate up hours and hours of fiddling 
and debugging time. For about six months I was using some insane mod_perl setup 
that failed so often I ended up writing blog posts in the error template that the server 
would send when something went wrong. So my first interest in yet-another 
publishing system was: Nothing more complicated than flat files. 

Second in 2005 it seemed like, just for a moment, that native XSLT 
processing was going to be a thing worth considering in web browsers. I might have 
been drunk when I thought this. Anyway it was just one symptom of that same 
fever-dream we've always been chasing: That there's some magic way of writing 
things down which is simultaneously easy to produce and to read with the naked eye 
but still sufficiently structured to allow for reuse and complex conditional display. 
Pure journey-not-the-destination stuff so there's really no point in arguing about the 
details. Eight years ago I chose XML and XSLT and next year you will choose 
something that will no better stand the test of time. 

Specifically I chose XHTML that stricter than strict reformulation of HTML 
that was going to save us all until a lot of people, quite rightly, pointed out that web 
browsers had long ago learned to deal with shoddy markup and less than perfect 
documents and maybe we all had better things to do than worrying about that stuff. 
But I went down that rabbit hole and came out with a way to publish blog posts that 
looks something like this: 

$> xsltproc — novalid \ 

-o ${LOCAL_CONTENT}/${l}/index.htinl \ 

$ {LOCALWEBLOG} /lib/xsl/bland/bland-nopref ixes . xsl \ 



$ { LOCALCONTENT } / $ { 1 } / index . xml 

The part where I am both invoking the — novalid flag and using an 
explicit no ( XML namespaces ) prefixes stylesheet should give you some 
indication of why trying to use the standard XML toolchain to convert HTML in to, 
well, HTML is generally a waste of time. I got it to work for myself but I wouldn't 
recommend the exercise to anyone else. It's not XML per se nor is it HTML. It's that 
the two "ways" of doing things came in to the world at roughly the same time and 
have a fundamentally split-brain relationship with one another like some awful 
sibling rivalry that can never be resolved. 

The stylesheet itself doesn't really do much other than wrap the contents in 
index . xml (the words you're reading now) in a fancy header and footer and 
include links to neighbouring blog posts and things like CSS stylesheets. I haven't 
bothered changing much about the design and stucture of this weblog in the last 
eight years but I have in the past and I might in the future. I like the idea of 
preserving past designs but more than that I like the idea that its something enforced 
by not re-rendering the source files (the words you're reading now) rather than 
tatoo-ing the present on the future. 

For example, this is index.xml / W ebiog/20i3/08/i8/pixeis/index-dot- 

xml.html and this is index.html /weblog/2013/08/18/pixels/index.html 
after it's been massaged by the stylesheet. So that's the setup. Remember that part of 
the fever-dream where there's a magic rendering fairy that will turn your eggs in to 
chickens and vice versa? Don't worry. This is actually the good part of the story. 
This is the part where things feel like they're getting a little bit better. 




I recently added the following CSS instruction to the (XSLT) stylesheet that 
renders blog posts: 

<link rel=" stylesheet " href ="http : //www. aaronland. inf o/css/weblog/print .ess" type=" text/ess " media= 

Since then I've slowly been working my backwards through the archives re- 
rendering things and adjusting the markup where necessary. It would be nice to tell 
you that I didn't need to tweak things but among this Weblog's many sins was the 
decision to wrap individual blog posts in <ins> tags because ... stupid? Also, all 
those presentation slides that need rescuing from Slideshare. Live and learn and 
somewhere during all of that the lovely Christian 

Plessl http://biog.piessiweb.ch/ wrote a command-line tool called 
wkpdf http://piessi.github.io/wkpdf/ that uses the WebKit rendering 
engine to convert HTML documents in to PDF documents. 



Although there are plenty of browsers available for Mac OS X, I could 
not find a command-line tool that allows for downloading a website and 
storing the rendered website as PDF. This was my motivation for 
creating wkpdf. The application uses Apple WebKit for rendering the 
HTML pages, thus the result should look similar to what you get when 
printing the webpage with Safari. 

Since wkpdf is based on the state-of-the-art WebKit HTML rendering 
framework, it provides high-quality web standard compliant HTML 
rendering with support for advanced CSS2/CSS3 styling. 



Because I've added a custom print.css stylesheet to all the rendered blog 
posts I can generate a handy PDF version simply by typing this on the command- 
line: 

$> wkpdf — no-caching -n — stylesheet-media print -p custom: 432x648 -m 48 54 72 48 — output index. c 

I am not creating PDF version of every blog post which really means sets of 
blog posts since there are often multiple posts that live under a single URL. Instead 
I've been bundling up all the blog posts for a single year and generating a single big 
honking PDF file. 2012 is 393 pages long; 201 1 has 379 pages; 2010 has 188 pages; 
2009 has 466 pages and so on. The page length is mostly to account for talks and 
presentations — remember Operation Escape from Slideshare? — which 
increasingly are delivered with novel-length notes and are formatted a bit differently 
in print than they are online. 




In talks of late I've been quick to mention that most of the Internet-based 
awesome we've all come to depend on is predicated on the power grid. I don't say 
these sorts of things to spook people but because I grew up in a place that is 
brutally- like-you-die cold most of the time and so you become keenly aware of the 
infrastucture that keeps you warm. Elecricity has become like oxygen, for most 
people, but it is not so its worth contemplating its absence and having some vague 
conceptual framework besides panic for dealing with its absence. 

If the power went out or the company that hosts this weblog went broke or 
every disk that keeps a copy of the source files suffered a catastrophic failure and 
the last eight years (fourteen really) went *poof* I would be sad. There might be 
more pressing matters to attend to if that happened but, you know, in principle and 
all that. 

So this — the ability to take a weblog (a creature born-digital if there ever 
was one) and dress it up as a book — feels like a way to think about those larger 
problems in small and tangible steps. If the End Days befall us then I don't know 



that I will choose to take these stacks of 

paper http: //www. aaronland.info/weblog/2 009/ 12/2 l/redacted/#2009 that 

outline the last couple decades but at least it will be a choice. The 

Papernet http://www.aaronland.info/papernet/ all the way down, right? 

In the meantime it also means that I have something (a PDF file per year of 
blog posts) more useful than a bag of raw HTML files to share with the Internet 

Archive https://archive.org/search. php?query=thisisaaronland .1 Still 

need to finish the years 2006 through 2008 but I am hoping that with everything I've 
learned doing 2009-2013 it won't take too much longer. Like the physical books it 
feels like a more concrete way to think about the problem of digital preservation 
sheltered, even just a little bit, from the actual enormity of the problem. 



I like that. 



There's a link above to the Internet Archive search results page for ? 
query=thisisaaronland https : //archive .org/search . php? 
query=thisisaaroniand but that endpoint seems to be a little flakey these days 
(as in: it returns no results) so I've also included links to the individual PDF files 
here. I'll add the rest as they get done. 

• thisisaaronland- 

2013.pdf https : / /archive. org/details/thisisaaronland-2 013 

— in progress and incomplete since it's still 2013 (for example this 
blog may not be included yet) 

• thisisaaronland- 

2012.pdf https : / /archive. org/details/thisisaaronland-2 012 

• thisisaaronland- 

20U.pdf https : / /archive . org/details/thisisaaronland-2 0 1 1 

• thisisaaronland- 

2010.pdf https://archive.org/details/thisisaaronland-2 010 

• thisisaaronland- 

2009.pdf https : //archive. org/details/thisisaaronland-2 009 

• thisisaaronland- 

2008.pdf https://archive.org/details/thisisaaronland-2 008 

• thisisaaronland-2007 

• thisisaaronland-2006 

I've also included the script I use to generate the annuals, below, as a 
reference. It uses wkpdf (mentioned above) to render individual HTML files and 
PDFbox https : / /pdf box . apache . org/ to stitch them all together. You should 
treat this code as nothing more than pseudo-code . It works but is very much specific 
to the corner(s) I've painted myself in to however the basic principles should apply 
regardless. 



#!/bin/sh 

# http://plessl.github.io/wkpdf/ 

# https://pdfbox.apache.org/ 

WKPDF="which wkpdf" 
JAVA= "which j a va " 

PDFBOX="${JAVA} -jar /usr/local/bin/pdfbox. jar" 

R00T=$1 
0UT=$2 

PARENT="basename $ROOT" 

if [ -z $OUT J 
then 

OUT=${ROOT> ' .pdf ' 

fi 
i=0 

for f in "find $ROOT -name ' index. xml ' -print- 
do 

i=$(($i+l)) 

num="printf "%02d" $i" 

# see what we're doing here... 

# it's kind of stupid... 

# oh well. . . 

f="dirname $f " ' /index. html ' 

f="python -c 'import os, sys; print os .path . realpath( sys . argv[ 1 ] ) ' $f 

r="dirname $f " 
r=" basename $r" 

TMP=' /tmp/ pdf -book- ' $ PARENT ' - ' $num' - ' $r ' .pdf ' 
echo "make ${TMP} from ${f}" 

${WKPDF} — no-caching -y print -p custom: 432x648 -m 48 54 72 48 -o $TMP -n -s $f 

done 

# Because I got bored of trying to figure out arrays in (ba)sh 

# Patches are definitely welcome... 

PDFDOCS= ' ' 
COUNT_DOCS=0 

for f in "Is -a / tmp/ pdf -book-$ {PARENT}-* . pdf" 
do 

C0UNT_D0CS=5 ( ( $C0UNT_D0CS+1 ) ) 

if [ [ -Z $PDFDOCS ] ] 
then 

PDFDOCS=$f 

else 

PDFDOCS=$PDFDOCS ' ' $f 

fi 

done 

if [ $COUNT_DOCS -gt 1 ] 
then 

echo "make ${OUT}" 

echo "${PDFBOX} PDFMerger $PDFDOCS ${OUT>" 
${PDFBOX} PDFMerger $PDFDOCS ${OUT} 

else 

echo "cp ${PDFDOCS} to ${OUT}" 
Cp ${PDFDOCS} ${OUT} 

fi 

# Apparently passing more than 6 documents to pdfbox makes it sad... 

if [ -f $OUT ] 
then 

for f in "Is -a / tmp/ pdf -book- $ { PARENT}-* . pdf" 
do 

echo "remove ${f}" 



rm $f 

done 

fi 



# Also, this works but sucks: 

# gin convert -density 150 -scale 864x1296 pdf-book-2012-* .pdf wtf.pdf 

echo "done" 
exit 
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A Timeline of Event Horizons 



This is a piece I wrote for the Cooper-Hewitt Labs 

blog http : / /labs . cooperhewitt . org/2 0 13 /a-timeline-of -event-horizons/ 

originally published on September 25, 2013. 




We've added a new experimental 
feature http://coiiection.cooperhewitt.0rg/experimentai/#t1 to the 
collections website. It's an interactive visualization depicting when an object was 
produced and when that object was collected using some of the major milestones 
and individuals involved in the Cooper-Hewitt's history itself as a bracketing 
device. 

Specifically the years 1835 when Andrew Carnegie was born and 2014 when 
the museum will re-open after a major renovation to Carnegie's New York City 
mansion where the collection is now housed. It's not that Andrew Carnegie's birth 
signals the beginning of time but rather it is the first of a series of events that shape 
the Cooper-Hewitt as we know it today. 



The timeline's goal is to visualize an individual object's history relative to 
the velocity of major events that define the larger collection. 

Many of those events overlap. The lives of Andrew Carnegie and the Hewitt 
Sisters all overlapped one another and they were all alive during the construction of 
Carnegie's mansion and the creation of Hewitt Sister's Cooper Union Museum for 
the Arts of Decoration. The life of the mansion overlaps the Cooper-Hewitt 
becoming part of the Smithsonian in 1976 and assuming the mantle of the National 
Design Museum in the mid-1990s. 

Wherever possible we show both the start and end dates for an object 
represented as its own underlined event span. If we only know the start date for an 
object we indicate that using a blue arrow. The date that the object was acquired by 
the museum is indicated using a white arrow. 



The soundtrack of histories that surround an object are depicted as a series of 
sequential and semi-transparent blocks layered one atop the other to try and reflect a 
density of proximate events. If you mouse over the label for an event it is 
highlighted, in orange, in the overall timeline. 

We had three motivations in creating the timeline: 

• To continue to develop a visual language to represent the richness and 
the complexity of our collection. To create views that allows a person 
to understand the outline of a history and invite further investigation. 

• To start understanding the ways in which we need to expose the 
collection metadata so that it can play nicely with data visualization 
tools. 

• To get our feet wet with the D3 Javascript library http://d3js.org 
which is currently the (friendly) 800-pound gorilla in the data 
visualization space. D3 is incredibly powerful but also a bit of a head- 
scratch to get started with so this is us, getting started. 

This is only the first of many more visualizations to come and we are hoping 
to develop a series of building blocks and methodologies to allow to build more and 
more experimental features as quickly as we can think of them. 



So head over to the experimental section of the collections 
website http://coiiection.cooperhewitt.0rg/experimentai/#t1 and enable 
the feature flag for the Object Timeline and have a play and let us know what you 
think! 




We've also made the Github repository for the underlying Javascript 
library that powers the timeline https://github.com/cooperhewitt/d3- 
timeiine-event-horizon public and released the code under a BSD license. It 
should be generic enough to work for any dataset that follows a similar pattern to 
ours and is not specific to a museum collection. 

If you look under the hood you might be horrified at what you see. We made 
a very conscious decision, at this stage of things while we get to know D3, to focus 
more on the functionality of the timeline itself rather than the elegance of the code. 
This is a very early experiment and we would be grateful for bug fixes and 
suggestions for how to make it better. 



2013-09-25 



Planetary: collecting and preserving 
code as a living object 



This is a piece I wrote with Seb Chan http://www.freshandnew.org/ for 

the Cooper-Hewitt Object of the Day 

Weblog https : //www. cooperhewitt.org/object-of-the- 

day/2 013/08/2 6/planetary-collecting-and-preserving-code-living-object , 

originally published on August 27, 2013. 

Cooper-Hewitt has just acquired its first piece of code. Although the 
collection has objects that are the end result of algorithmic processes, notably 
Patrick Jouin's 3D printed chair, Solid 

C2 http://collection.cooperhewitt.org/objects/18733547/ , this is the first 

time that code, itself, has been collected. 

Almost all contemporary design practice involves digital processes — from 
the ubiquitous Adobe design software to CAD packages used by product designers 
and architects, to the simple day-to-day office management and accounting software 
— it would be difficult to find a designer who lives entirely 'off the grid.' Despite 
this, design museums have been slow to start to add software to their permanent 
collections. 

Some of this reticence to collect digital objects stems from deep 



uncertainties as to how to preserve and present such objects to future visitors and 
future scholars. But for Cooper-Hewitt these uncertainties have been a strong driver 
to experiment. 

So, here we have Planetary. 

Planetary is an iPad application written in C++ using the Cinder 
framework http : //libcinder . org/ . Planetary offers an alternative music 
player application for the iPad that visualizes your music collection as a series of 
celestial bodies. Songs are moons, albums are planets, artists are suns — and the 
orbits of each are determined by the length of albums and tracks. Their brightness 
represents their frequency of playback. 

It is an elegant interactive visualization produced as the first product by 
Bloom, a San Francisco startup founded in 2010 by Ben Cerveny, Tom Carden, and 
Jesper Andersen, to explore new forms of data visualization and interactive 
products. In the company's introductory blog 

post http://biog.bioom.io/20ii/02/2i/inbioom/ in2011 Cerveny wrote: 



"We're building a series of bite-sized applications (instruments) that 
bring the richness of game interactions and the design values of motion 
graphics to the depth and breadth of social network activity, locative 
tools, and streaming media services. . . . These Bloom Instruments aren't 
merely games or graphics. They're new ways of seeing what's 
important." 

Planetary was the first of those instruments, written alongside artist/coder 
Robert Hodgin http : / / roberthodgin .com/ who joined for the duration of the 
project, and to date it has been downloaded more than 3.5 million times. 

We have acquired Planetary both as an example of interaction design and 
interactive data visualization, but by acquiring its source code — including its 
changes between versions — we are also able to reveal the underlying design 



decisions made through its creation and evolution from its first public release in 
201 1 to the last public version of 2012. 

The acquisition of the source code also allows us to do something else very 
important. 

Preservation 

Like all software, Planetary has been skirting obsolescence almost from the 
moment it was released. Software and hardware are separate but inescapable 
companions that exact a sometimes profound and warping, and sometimes 
destructive, influence on one another. 



(in-app planet texture detail) 

Software written for the first iPhones, released only six years ago in 2007, 
no longer works on today's iPhones. It might be because the operating system was 
taught a fresh new way of thinking about things. It might be because new hardware 
was invented that is foreign to and misunderstood by the past. Often it's both. 



Tom Carden has written: 



"Planetary was written for iOS 4.3. Since iOS 5 was released it has had 
bugs and glitches interfacing with the music player code/library 
provided by Apple. We reported the 

bug http: //stackoverf low.com/questions/10118726/getting- 
wrong-playback-state-in-mp-music-player-controller-in-ios- 
5 but it has not been fixed yet. I hold out hope that it will be fixed in 
iOS 7. In 4.3 all music was local to the device. Since 5 (I think) it's been 
possible to have various forms of streams and clouds from the same 
API , which is now a creaky/leaky 

abstraction http: / /www. joelonsoftware.com/articles/LeakyAbstractions .html 

"Planetary is the last of a generation of OpenGL apps to benefit from the 
fixed function pipeline. From here on out the future is shaders, in all 
their abstracted/obtruse glory. So much more power but also takes a lot 
more time and effort to wrangle an expressive framework. Further, it's 
fascinating to me that everything I learned about OpenGL on a $5000 
SGI workstation in 1999 was relevant (still basically current) on the 
$500 iPadin 2011." 



This is okay. It's the price of living in the present. But it does make our jobs 
as cultural heritage institutions harder. 

Museums like ours are used to collecting exemplary achievements made 
manifest in physical form; or at least things whose decay we believe we can combat 
and slow. To that end we employ highly trained conservators who have learned their 
craft often over decades of training, to preserve what would often be forgotten and 
more quickly turn to dust. 

But preserving large, complex and interdependent systems whose 
component pieces are often simply flirting with each other rather than holding hands 
is uncharted territory. Trying to preserve large, complex and interdependent systems 
whose only manifestation is conceptual — interaction design say or service design 
— is harder still. 



As daunting a task as that may be, we choose to see opportunity. 



With Planetary we are hoping to preserve more than simply the vessel, more 
than an instantiation of software and hardware frozen at a moment in time: Commit 
message 

fd247e35de9138f0ac411ea0b261fab21936c6e6 https : //github.com/cooperhewit 
authored in 201 1 and an iPad2 to be specific. 

In order to do this, or fail trying, we are open sourcing the code that runs 
Planetary. 

Although Bloom folded in 2012, its three principals have not only gifted the 
code for Planetary to Cooper-Hewitt they have also given us explicit permission to 
publicly release the source code under an open source (BSD) license, and its 
graphical assets under a Creative Commons (non-commercial) license. 

The Source Code https://github.com/cooperhewitt/Planetary is 

currently hosted in Cooper-Hewitt's repository on GitHub as is a second repository 
called PlanetaryExtraS https://github.com/cooperhewitt/PlanetaryExtras 
that contains images, screenshots, notes, and drafts that were made during the 
creation of Planetary itself. Think of that second repository as the 'curatorial folder' 
of all the additional materials - except that it is out in public. 




(early mockup of interface) 



This means that anyone can now look at, 

download https://github.com/cooperhewitt/Planetary , and play with the 

source code that makes this app. Not only that, you are permitted to replicate, 
modify, and transport it to other hardware platforms and devices. 

You can even apply the concept — nested data sets visualized and behaving 
as celestial systems — to other types of data and contexts. 

Could we, for example, depict the Enron email 
dataset https://www.cs.cmu.edu/-enron/ with its half-million messages using 
Planetary? Or if we included Planetary in the Google Art 

Project http : / /www. google . com/culturalinstitute/collection/ cooper- 
hewitt-national-design-museum (to which we contribute) could we do it in a 
way that both preserved its interactivity and displayed the entirety of the collections 
in the Art Project itself? 

Of course, Planetary will still be available from the Apple 
AppStore https: //itunes. apple.com/us/app/planetary/id4324623 05 ?mt=8 
for the foreseeable future although it will no longer be officially supported. Or 
rather, not actively supported. 

Cooper-Hewitt itself will not be actively developing new versions of the 
application but we hope that the wider communities of developers, scholars, and 
enthusiasts will. Bloom's choice to develop Planetary for Apple's iOS operating 
system and the iPad (but not the iPhone) helps us to understand the technological 
landscape in which Planetary was conceived although it is important to realize that 
Planetary is not, first, an iPad application. 

Instead, we believe that Planetary is foremost an interaction design that 
found its "then-best manifestation" in the iPad. What might that choice look like 
today? 

Three years since its first release, hardware and software environments akin 



to those of the first iPad are available from a variety of sources. We are hopeful that 
people will think that Planetary is as interesting as we do, and will consider porting 
the code to work on Android devices or in a web browser using WebGL or large 
interactive surfaces (which are increasingly indistinguishable from large desktop 
computers or increasingly internet-connected televisions). 

While Ben Cerveny was at Stamen Design http://www.stamen.com he 
and founder Eric Rodenbeck (also a former National Design 

Awards http://www.cooperhewitt.org/national-design- 

awards/about/history juror) developed a conceptual approach to their work 
centered around the idea that "data visualization is a 

medium http : / /blip . tv/oreilly-emerging-technology-conf erence/eric- 
rodenbeck-inf ormation-visualization-is-a-medium-1024510 " . Tom Carden 

has also pointed out that: Google/IBM's Martin Wattenberg and Fernanda 
Viegas http : //hint . fm also drove this agenda, independently, around the same 
time. 

We agree! 

We hope to use this acquisition as a vehicle to actively explore and ask the 
question of how we meaningfully preserve the experience of using the software. 

As part of that exercise Tom Carden has agreed, for a time, to oversee and 
be the final arbiter of any bug fixes and updates and (hopefully) newer versions of 
the code that will allow the software — the interactivity — to live on beyond the 
iPad. Tom won't do this forever, but by agreeing to participate for a time it will 
allow us to better understand how museums might preserve not only the form of the 
things in their collections, but their creator's intent. 

The distinction between preservation and access is increasingly blurred. This 
is especially true for digital objects. 

We already have a number of "digital" objects in our collection, from 
calculators to desktop computers to iPads and iPhones, but we have only collected 
their physical form. The 



iPhone http://collection.cooperhewitt.org/objects/18733051/ in our 

collection is neither powered on nor has it been kept up to date with newer software 
releases. Eventually the hardware itself might be considered so delicate that to 
power it on at all would damage it beyond repair — a curse common to many 
electronic objects in science and technology collections. How then do we preserve 
the richness and novelty of the software interfaces that were developed and 
contributed equally if not more than the industrial design to that device's success? 

We cannot pretend to have all the answers to these questions but we think it's 
important to start making the effort to find some of them. 



( Graffiti, Amsterdam, 2013, photography by Aaron Straup Cope) 



Living objects 

We liken this situation to that of a specimen in a zoo. In fact, given that the 
Smithsonian also runs the National Zoo, consider Planetary as akin to a panda. 
Planetary and other software like it are living objects. Their acquisition by the 
museum, does not and should not seal them in carbonite like Han Solo. Instead, 
their acquisition simply transfers them to a new home environment where they can 
be cared for out of the wild, and where their continued genetic preservation requires 
an active breeding program and community engagement and interest. Open sourcing 
the code is akin to a panda breeding program. If there is enough interest then we 
believe that Planetary's DNA will live on in other skin on other platforms. Of course 
we will preserve the original, but it will be 'experienced' through its offspring. 

In a similar vein Wolfgang Ernst of the Media Archaeology Lab at Berlin's 
Humbolt University, has 

Said http: //blogs . loc . gov/digitalpreservation/2 013/02 /archives- 
mat eriality-and-agency-of- the -machine-an-interview-with-wo If gang- 
ernst/ that: 



"Following my definition that such items need to be displayed in action 
to reveal their media essentiality (otherwise a medium like a TV set is 
nothing but a piece of furniture), it required an assembly of past media 
objects which teachers and students are allowed to operate with and to 
touch upon — a limit for curators and visitors in most museums of 
technology." 

"The main feature of the [Media Archeological Fundus] MAF is 
grounded in the materiality (called 'hardware') of media artifacts — just 
as the Signal Laboratory is archaeologically rooted in the source codes 
of computer programs (since the memory regime of media culture is 
both material and symbolic, both engineering and mathematics). The 
configuration of artifacts in the MAF, guided by rather idiosyncratic 
media-epistemological criteria of teaching and research, does not 
constitute an archive, and its online presence is not meant to contribute 
to audiovisual archives as represented in the Web but rather a different 
form of audiovisual argumentation. Rethinking dynamic digital memory 
requires different platforms." 



New opportunities for research and scholarship 

As a research institution we are also interested in reaching new 
understandings of the ways designers use code that can be gleaned from the code 
itself. 

As we are acquiring a source code from the version control system that it 
was managed in (also GitHub) , we have been able to preserve all the documentation 
of bugs, feature additions, and code changes throughout Planetary's life. This offers 
many new interpretive opportunities and reveals many of the decisions made by the 
designers in creating the application. 

Not only that, we are interested in the application of literary and text analysis 
methods to the source code which could enable future scholars to explore the 
'writing style' and 'aesthetic' that the designers used in writing this application. If we 
were to acquire other software by these same authors in the future, would we be 
able to find similar linguistic 



practices https://github.com/fiight404/Eyeo20i2 unique to their particular 
styles of coding? 




(Archival version of Planetary sitting on the shelf - center left - amongst 
other flat objects in our collection stores as DIG001) 

To be safe, we have also printed out a full copy of the source code on 
archival paper in the 1960s machine-readable OCR- A 

font http://en.wikipedia.org/wiki/OCR-A_font - meaning that should the 

online version of the code ever be lost or corrupted we have a 'master' copy deep 
inside the vault. 

The future? 

As more of the world we live in is designed, controlled, and surveilled by 
code, should the nation's design museum not begin to acquire the underlying source 
code of all its objects - from CAD models of furniture, to the code that optimizes 
the fuel injection systems of the latest car, the to the algorithms that underpin the 
financial 

Systems http: //www. ted. com/ talks /kevin_sl avinhowalgor it hmsshapeourw 



that drive Wall St? 



The author and journalist Clive Thompson has written a lovely article about 
the Planetary acquisition for Smithsonian 

Magazine http://www.smithsonianmag.com/arts-culture/smithsonian- 
institution/How-Does-a-Museum-Acquire-an-iPad-App-f or-its-Collections- 
220570391. html sowe encourage you to have a read of that as well as Robert 
Hodgin's excellent blog post, Creating new 

worlds http : / /blog . bloom. io/2 0 11/07/1 1 /creating-new-worlds/ , about 
designing and building the planets in Planetary and then explore the Github 
repository https://github.com/cooperhewitt/Planetary and help US figure 
out how we make the present safe for the future. 

Or just go and download 

it https://itunes.apple.com/app/planetary/id432462 305 and run it on your 

iPad. 



"This is a field in which one does one's work and it will be obsolete 
within 10 years." — Steve Jobs http://www.youtube.com/watch? 

v=zut2NLMVL_k , 1994 
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Dan http : / /www . revdancatt . com/ said something the other day that I've 
said every way but actually saying it because I still don't want to believe it. He 

Said https://twitter.com/revdancatt/status/386204919872897024 : "Ah, 

Flickr, Feb 2004 - Oct 2013, we had a good run but clearly it's time for us to go our 
separate ways, we just want different things." 

I haven't posted anything that meaningfully looks like a photo to Flickr since 
the launch of the Biggr (sic) redesign in May of this year. Almost as soon as the 
redesign went live I taught Parallel Flickr http://straup.github.io/paraiiei- 
f lickr/ to upload photos to itself but not necessarily to Flickr. In that way the 
software learned all the tricks of 

Privatesquare http://straup.github.io/privatesquare/ which has always 
been a kind of looking glass archive, capturing the activity to be archived but only 
maybe sending in on to the nominal source or service to be archived. Pushing photo 
uploads through that kind of looking glass necessitated a bunch of interesting 
architecture and software decisions but I'll save that discussion for another blog 
post. 



Your photos 




I also taught Parallel Flickr to generate stylized — obfuscated, really — 
thumbnails of uploads that it controlled and those would be posted to Flickr (and 
promptly archived in turn because Parallel Flickr uses the real-time Flickr PuSH 

feeds http : / /code .flickr . net / 2 011/10/11 /talk-real-time-updates-on-the- 
cheap-for-fun-and-prof it/ to archive photos). This was an experiment to try 
and use Flickr as a kind of signal fire to let people know that I was taking photos, 
just "over there". In Twitter's early days Kellan http://www.iaughingmeme.org/ 
used to talk a lot about how Flickr might use it as a notification system for photo 
uploads. I don't know if his suggestions would have worked at the time but I've 
always rememebered them and so, in 2013, 1 wondered if Flickr itself might be used 
as that signaling mechanism (for things I'd uploaded to Parallel Flickr). In the end 
people just hated all the pixelated photos and wondered what I was on about this 
time. 



Around the time of the big groups 

redesign http://www.fiickr.com/photos/straup/9420447504/ , where every 
group was assigned a canned thumbnail with little bearing to reality and less to the 
group itself, I more or less gave up. Any photos not already public were replaced 
with a placeholder which continues to be a rich source of hilarity and unexpected 
consequences for me and Parallel Flickr but that's also a story for another time. I 
haven't done much since then. I still favourite photos occassionally and Parallel 



Flickr dutifully backs them up. I have a 2004-2013 in-the-style-of- 

Heather http://www.flickr.com/photos/heather "last photo" sitting 

somewhere on my laptop but I haven't posted it and I don't know if I will. 
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Although it remains a real possibility (because you know, Yahoo) unless 
Yahoo manages to completely poison the well I try to remind myself that Flickr is 
(was?) a photo-sharing website and that we encouraged people to share photos with 
each other. Purging all those photos and links out of anger doesn't really square with 
everything we tried to build over the years. So for now they stay. Mostly, though, I 
am not ready to believe that it's over. 



That's the sad-making part of this blog post. I'm not really interested in a 
longer discussion of all the ways it hurts to use the site these days. I am heartbroken 
to watch everything we did being dismantled but we all left and might all be dead if 
we'd stayed any longer than we did so this is what happened instead. And I don't 
honestly know what happens next. Talk is cheap but photo- sharing, done right, is 
still hard. 




I've been joking with people that my Little Printer is my new photo- 
sharing service https://github.com/straup/littleprinter-tools . I Send 
myself (and M.) photos and tape the print-outs to the wall and watch as they curl 
and yellow and slowly vanish. In all the talk about ephemera, these days, there is 
something pleasant in the tangible finality of thermal paper. Recently, 
mroth http: //mroth. info/ and I joked about building "SnapHop" , a service 
that lets you upload photos which are only visible in a year's time. I was going to 
build that on the flight home but I still have a day job trying to re-open a 
museum http : / / labs . cooperhewitt . org/ so there are actual limits to how 
much time I can spend with all this crap. 

None of the upload-to-self stuff in Parallel Flickr that Fve talked about is 
enabled by default either but I might set aside a couple of days to document its 
current state and list all the gotchas and just push it out of the nest. 



Somewhere in all of this, Mike Migurski http://mike.teczno.com/ 
decided to archive his Pinterest account as a book. He wrote the code to read a CSV 
dump of all his Pinterest posts and then automagically figure out how to place the 
optimal number of (up to 4) photos on a single page and then generate a PDF file of 
the whole thing. Mike's Pinterest account was pretty epic so printing a single image 
per page would have resulted in a book too large to be bound and too expensive to 
imagine. They are lovely books and so one day I asked Mike if he would share the 
source code with me. And he did. 




It was, he pointed out, very much specific to his needs and to the vagueries 
of the Pinterest API but I've been poking at it since then and with Mike's blessing 
have released the code on Github under the name 

"4up https://github.com/straup/4up ". It's called 4up because I needed a 
quick, pithy name for the then-private repo and it's sort of catchy and because the 
code usually manages to lay things out four to a page. 



The first task was figure out what bits of the Pinterest API and resultant CSV 
file were actually necessary to use the code with another source. As of this writing 
I've managed to pare it down to the following: 

full_img, id,meta 

For example, this is what one row in a CSV file full of Flickr photos might 
look like: 

http://farml.staticflickr.eom/l/132429_ob520f81oe.jpg, 132429, "{""og: description" " : " "untitled- 1 , by 

If you're looking carefully at the example above and wondering why the 
various properties are named the way they are it's only because this is still early 
days and I've been more concerned with identifying the bits that can be removed 
rather than what things should or should not be named. So og : description and 
pinterestapp : source it is, for now. 

Then, thanks to Mike, all you need to do to generate a big honking PDF file 

is: 

$> python . /layout. py -d data/f lickr-photos-2005 . csv 

And then you'll end up with something like this: 




That's about where things stand today. The repository has helper scripts for 
generating 4up "compliant" CSV files for a user's photos or favourited photos on 
Flickr: 

$> python . It lickr/4up-photos . py -c flickr. cfg -u me -o ../data 

The scripts will dump all the photos in to CSV files grouped by year 
uploaded or year faved. There are still lots of limitations to the code including the 
part where the Flickr helper tools are all written to use old-skool Flickr Auth API 
token instead of the newer OAuth credentials so if someone wants to send a pull 
request to deal with that I'd be grateful. The code itself can be found over here: 

https://github.COm/straup/4up https : //github.com/straup/4up 

Update: hugovk has already sent in a 
patch https://github.eom/straup/4up/puii/i# to make the Flickr scripts 
work with the new OAuth API bits. Yay! 

Beyond that there are all sorts of details and edge cases to solve: How to 



manage really long books without running out of memory or splitting them in to 
multiple books or being clever about page numbers if they are. The default number 
of pages for a book is 240 but you can configure that manually although a book of 
Flickr photos 300 pages long caused the machine I'm working to throw a hissy fit 
and stop working. Or splitting books based on overall file size rather than page 
number (notwithstanding the running out of memory problem) because services like 
Lulu won't let you work with individual files that are larger than 2GB . 




The good news is that there is (not super user-friendly yet) code which 
should be able to create hot Mike-style books from any source that can be squeezed 
in to the CSV format described above. I've been focussing on Flickr photos and 
have yet to send anything out to be printed yet so there may be a few revisions left 
before its anything like a general purpose tool but / think this is a nice happy- 
making antidote to all that other gloomy stuff I started with. 

This was going to be the part where I mentioned that I would absolutely 
consider uploading these "books" to the Internet Archive, along the same lines of 
the PDF versions of this weblog that I talked about in the 



papernet.CSS http: //www.aaronland.info/weblog/2 013/0 8/18/pixels/#papernet 
dot-ess blog post. I was going to mention this because the problem with doing 
that is that any book of Flickr photos will likely contain lots of not-public photos 
and there are really only binary public/invisible privacy controls on things uploaded 
to the Archive. 

If the Archive implemented a 70-year rule (or 40, or 100) that would allow 
me to upload things which would remain private until a certain date — a kind of 
"SnapHop" for cultural heritage even — I wouldn't think twice about sharing my 
Flickr photos. As it is now it's all or nothing and that feels like a problem people in 
the so-called memory business need to think about. 
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Having already gone through my Flickr photos and "redacted" all the private 
and friends-family photos it's actually not a problem I have anymore but it's another 
example of an idea I touched on, in the Quantified 

Selfies http: //www. aaronland.info/weblog/20 13/07/25 /verb/#quantif ied 
talk, last summer, that there needs to be: "an explicit contract where ... the Library 
promises to preserve the permissions model in the present in exchange for a person 



gifting that present to the future." 

In the meantime, books. Or photo albums. Or small tools for ...uh, artisanal 
photo- sharing? Or something like that. 



2013-09-06 



today's episode of the office 
has been redacted 

the present happened 



the present happened 




LastweekSeb http://www.sebchan.com/ and I spoke at the 
Australian Institute for the Conservation of Cultural Material National 
Conference http://www.aiccm.org.au/ . We talked about the Cooper- 
Hewitt's acquistion of 

Planetary http: //www. cooper hewitt . org/ob ject-of -the- 

day/2 013 / 08/2 6/planetary-collecting-and-preserving-code-living- 

ob ject , earlier this year. We were not in Australia but instead we used 
the magic of the Internets to connect our respective homes to an 
assembled audience in Adelaide ( who also were in the "future ") which 
when you think about it is sort of amazing. After some technical hiccups I 
ended up sharing my screen with the conference attendees which meant 
that I couldn't see them. So as you read this just imagine me sitting on my 
couch talking at my laptop. This is what I said, taking in to account the 
part where the reality is always edited and embellished a little in the re- 
telling. 



I'd like to start with a very condensed history of the Cooper- 
Hewitt. In 1897 Sarah and Eleanor Hewitt opened the Cooper Union 
Museum for the Arts of Decoration. It was so named after the Cooper 
Union, founded by their grandfather Peter, where the collection was 
housed. 



In 1903 Andrew Carnegie built himself a mansion in what is now 
New York City's Upper East Side. The mansion still stands and for those 
of you familiar with the major sites in New York it is located a block 
north of the Guggenheim museum, famously designed by of Frank Lloyd 
Wright. The mansion will become relevant in a moment. 



Like right now. By the late 1960s the original decorative arts 
museum was no longer financially viable and the Smithsonian agreed to 
take on the collection. At the same time the Smithsonian was in 
discussions with Andrew Carnegie's family to assume the stewardship of 
the same mansion I just told you about. You can guess what happened 
next and in 1976 the doors to Andrew Carnegie's mansion re-opened to 
the public as the Cooper-Hewitt Design Museum so that they could once 
more enjoy the collection that the Hewitt sisters had acquired over the 
years. 



In 1992 the Cooper-Hewitt assumed the mantle of the National 
Design Museum and began to make design, rather than decorative arts, its 
primary focus. We are still charged with the long term care and study of 
the Hewitt sisters collection but we spend most of time thinking about 
capital-D design as most people now know it. 

In 201 1 the museum closed its doors to complete a historic 
restoration of the mansion and to re-imagine what it means for a museum 
to embrace the Internet, in body and spirit. To treat the Network, and all 
the opportunities and challenges it presents, as a part of the museum itself 
rather than a rubber ducky floating alone in the bathtub. If that sounds a 
bit hand-wavey that's because it is. A big part of our job on the digital 
team is to make those ideas tangible intellectually but then also to build 
them. 



Vacuum Cleaner, "iRobot Roomba Vacuuming Robot", 2002 

Plastic, metal. Gift of iRobot. 2008-30-1 -a/k. 




Quickly, for those of you wondering about the two arrows in this 
timeline they represent the year that we acquired a Roomba in to our 
collection (2008) and the year that it was first produced (2002). The 
timeline is an experimental 

feature http: / /labs . cooper hewitt . org/2013/a-timeline-of -event- 
horizons/ we've enabled on our collections website to try and situate an 
object within the velocity of the major events in the museum's history, but 
that's another talk for another time. 




The original Museum for the Arts of Decoration was what is called 
a "working collection". The museum was meant to be an active space not 
just for learning about the history of decorative arts but for training 
amateur and professional crafts people alike. 

So the Hewitt sisters' approach to collecting artifacts was by 
comparative standards of their day encyclopedic. All of this was 
happening in a time before capital-D design even existed. Before design 
there was the decorative arts. Before during and after the decorative arts 
there have always been crafts people and they have always learned by 
watching and copying the work that came before them. 
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So we have all the sporks. And the spoons. And the forks, too. We 
have all the things you'd expect a pair of wealthy, well-intentioned 
members of New York City's upper class to be collecting at the end of the 
18th century. Which means we have a lot of stuff from 

France http://collection.cooperhewitt.org/countries/ . You 

don't choose your family, right? 




Some of you may be wondering how a museum like ours squares 
the goal of an encyclopedic collection in a world where we are buffeted on 
both sides by private corporations and the public alike. 

On one side we live in a world where companies like Target and 
Amazon exist. Their enormous catalog and warehouses full of products 
make the Hewitt sister's endeavour seem sort of quaint when looked at in 
the cold hard light of the 21st century. If you still doubt me stop for a 
moment and consider what it means when Amazon hires a staff of 
professional curators and gives them not simply a mandate but the 
resources to pursue it. What if they not only give them a mandate but an 
endowment? 



That sounds a bit like... a museum. 



At the same time, the existence of these companies coupled with a 
steady rise in the availability of networked databases (without which 
companies like Amazon couldn't survive) means that people's expectations 
about the breadth and volume of information available to use are rapidly 
outpacing our ability to meet them. "We are forever" we tell ourselves but 
short of some sort of catastrophic failure at a societal level, at which point 
we will have much bigger problems on our hands, we will continue to be 
judged against the standards of contemporary convenience. 

I have remarked in the past that the distinction between libraries 
and museums and archives is collapsing in the minds of most people who 
work outside of those professions. I'm not sure that the distinction ever 
existed for some people. That is not the subject of this talk but I want to 
raise the issue and then send it off to sit in the corner. We'll point at it a 
few times during the rest of this talk. 




This is a talk about digital preservation and specifically about a 
piece of software, an iPad app called Planetary, that the Cooper-Hewitt 
acquired earlier this year. We will talk about Planetary but I'm going to 
take the scenic route to get there. Our motivation and our approach to 
acquiring Planetary do not exist in a vacuum and it is important to 
understand the context in which the acquisition was made. 

There's a running joke that the Smithsonian is the nation's attic. 
Some people bristle at this description but I am among those who 
celebrate it. I actually think that the Smithsonian's mandate to collect 
maybe not all but many of the things on-a-scale-as-to-seem-like-most-of- 
them under the aegis of the federal government is pretty amazing. We 
have spaceships and pandas and masterworks in the fine arts. We have 
vacuum cleaners and sporks. And we collect all this stuff because, as a 
society, we believe it is important to remember the role these artifacts 



played in the history of the United States. 

And its an idea that extends beyond the past. Despite all the jokes 
and on-going concerns about the US economy and its political class acting 
like chaos-monkeys America isn't going anywhere anytime soon so we 
have both a responsibility and an opportunity as a public institution to pay 
attention to and to actively collect the future-now. 

To pay attention to the present in the service of the past. 




So here we are. We are an arm of a large publicly funded cultural 
heritage institution with a mandate to promote an awareness and 
appreciation of design. Design, not art. Or put another way objects that are 
the manifestation of a solution to a stated problem rather the singular 
exemplary itch of an artist. 

But we — and by "we" I mean all design museums — are not 
immune to the thrill and allure of hero objects. 

In case you're wondering, this chair might be a hero object to 
some but is not part of our collection. I found it in an antique shop in 
Brooklyn. Maybe it should be part of our collection and given some of 
things the museum, never mind the Hewitt sisters, has collected over the 
years I could make a pretty compelling case that it already was. 




Like the relationship between libraries and archives and museums I 
want to float another open question but only long enough to see it and then 
send it to stand in the corner with the other tangents and sidecar 
conversations. I want to ask why it is that we celebrate certain 
instantiations of a design object over others. Why is a chair designed by 
Ray and Charles Eames more special - why is it the hero object - the 
closer it is to its creators? 



These are supposed to be objects whose purpose embodies a 
uniform reproducibility. Many of the other museums, art museums and 
design museums alike, in New York City have their own copies of the 
classic Eames armchair (and ottoman) but we would crawl and scratch our 
way over each other if we thought we could get our hands on a chair that 
rolled of the very first assembly line rather than something produced to the 
same exact standards of the time, in 2013. 



What about Osama bin Laden's AK-47 that the CIA "acquired" in 
201 1 and is on view in their own private 

museum http://rt.com/usa/cia-bin-laden-ak47-593/ ? Is that a 

genuine "hero object" or just one of many that roll of the assembly lines 
and in to armed conflict every year? 

Like I said this is an entirely other conversation but it's not one that 
we escape easily (or ignore wisely) in the day-to-day of our role as a 
design museum. It's not a distinction that I think makes a whole lot of 
sense for product design and it makes even less sense applied to software. 



This is a project by Timo Arnall and J0rn Knutsen and Einar Sneve 
Martinussen to visualize the presence and strength of available wireless 
signals along a path by painting the terrain in 

light http://www.nearfield.org/2011/02/wifi-light-painting . 

If any of you grew up in the 1980s you might remember the 
endless chorus of people telling you that, with the advent of the personal 
computer and ever-cheaper computing power in general, everything was 
going to dissolve in to ones and zeroes. Except that it didn't happen. Not 
in the 1980s at least and I think everyone sort of felt like they'd been cried 
"wolf" to and carried on. And then somewhere between then and now 
everything really did start dissolving into ones and zeroes. Without 
anyone really noticing. 



Ana mat maKes ror a lot or conrusmg moments, witnout a wnoie 
lot of warning, the present happened. 

This is kind of a big deal for a museum charged with preserving 
design because the things we're meant to showcase are increasingly 
intangible. Some designs might have manifestations or instantiations but 
sometimes (by which I mean more and more often) there is no single Ur- 
object that can serve to crystallize its importance. 

We can not snapshot every waking moment - although some 
people keep trying - but it seems a shame and an abdication of our 
responsibility to simply throw up our hands and say that the best we can 
do for things that can't be objectified, literally, is to take a couple pictures 
and jot down a few descriptive paragraphs. That feels like we're not trying 
very hard at best and actively moving backwards at worst. 




For example, service design. Or experience design. The two often 
go hand in hand. Whatever their relationship they are also very real design 
practices. Lots of really smart people spend their lives thinking about how 
you apply the principles of successful traditional design to systems that 
are more complex than a single object and increasingly have no tangible 
form at all. 




I've been joking for the last year that the Cooper-Hewitt has 
acquired the War on Terror as an outstanding example of service design. 
Sometimes I say that we acquired it because it's an exceptional piece of 
experience design. Most people are confused and horrified by that idea 
which is, I think, the correct response. If you're not confused and horrified 
stop for a moment and consider what that means. 

Do we have interactive museum experiences where we lock you in 
a room with an angry dog? Do you get to waterboard your sister? Maybe 
you can buy an orange jumpsuit at the gift shop or sign up for a weekend 
package where you get force fed through an intravenous 

tube http: / /www. theguardian. com/world/video/2013/ jul/ 08/mos- 
def-f orce-f ed-guantanamo-bay-video like the rapper MoS Def did, or 

rather tried to do, a few months ago. 



This is an actual waterboarding device so there is some precedent 
for thinking that sooner or later the Global War on Terror, so-called, will 
be collected by a museum. If you don't recognize this image it was taken 
at the Tuol Sleng Genocide Museum http://www.tuoisieng.com/ in 
Phnom Penh. The museum is housed in the building that used to be 
Security Prison 21 where it is said that up to twenty thousand people were 
killed during the years that the Khmer Rouge was in power. 

Is this a design object in its own right? Is the War on Terror a 
design object? I don't know but I use it as an example precisely because 
it's so extreme. The War on Terror is certainly deliberate and orchestrated 
with, so we're told, a stated end goal and I'm pretty sure that it's passed the 
production and manufacturing test we typically use to distinguish design 
from craft. 

Is this not how we usually distinguish design from the other 
disciplines? 



The friendlier version of this story is the one I tell about Virgin 
America. If we were going to talk about collecting any single instance of 
contemporary American service design as exemplary then Virgin America 
is probably it. 

The entire process of flying from point A to point B with Virgin 
America was designed as a signal "experience" spread over the entirety of 
that transaction. The attention to detail starts - or more accurately started 
since Virgin eventually switched to using the same backend ticketing 
system that plagues every other airline - with your visit to their website to 
book your flight to the design of their aircraft interiors and, if you're flying 
to San Francisco, all the way to the airport terminal itself complete with its 
tasteful mid-century modernist seating. 



All of this while often very pleasant is also very very deliberate. 

But what exactly do we as a design museum collect? How do we 
capture the spirit of what Virgin America's designers have created? Do we 
collect a sectional piece of the interior of one of their airplanes with their 
characteristic purple lights? Do we acquire the safety video with cartoon 
characters and cheeky copy? How about the minimalist checkin counters 
with their quirky square boarding passes? That's a thing that people could 
take home with them which is hard to argue with. Everyone loves taking 
things out of museums. 

Or to really explain to people how successful Virgin America has 
been at changing what people expect from a passenger airline do we, as a 
friend once suggested, need to first create an interactive experience that 
distills everything bad about American airports and airlines in the 21st 
century and which people must pass through first before they see the 
alternative? 

Perhaps instead we should consider acquiring the rights to operate 
the San Francisco to New York route and sell tickets to people wanting to 
understand what it meant to travel in an end-to-end design experience. But 
we don't really know the first thing about airplanes so I don't think that we 
should be allowed to do that. Being part of the Smithsonian we could 
probably partner with the Air and Space Museum since they know all 
about airplanes and then work out a deal with Smithsonian Enterprises, the 
commercial arm of the Smithsonian, to sell package tours. It's all 
surprisingly more possible than you'd imagine if you're part of something 
the size of the Smithsonian but not everyone has that luxury of 
association. 



Think of these stories less as specific but rather indicative 
examples of another larger phenomenon that museums are struggling with. 
The things we collect are no longer just static objects which can be 
preserved in amber or in static-free mylar bags. We are collecting things 
that in order to be properly maintained and studied need to keep working. 
We are increasingly in the business of operating services, which is new 
and uncharted and often terrifying territory for many institutions. 



We do this already, really, but what's changed is that we need to 
start thinking about and treating our objects the way we treat museum 
visitors. 







E_EXCESSIVE_EXPERIENCE 
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Recently, we acquired a couple of programmable themostats from 
Nest, a company founded by some of the original designers of Apple's 
iPod. 

That's cool. It's also true that you could order one for yourself too, 
right now, but long after the company has gone on to other endeavours we 
will continue to keep ours safe from harm and off-gassing so that the 
future might better appreciate the early days of the networked home. 

Or will they? 

I'm probably not supposed to ask this question in public but I will 
anyway: If most of what constitutes the magic in a Nest thermostat is 
defined by its software and interactivity what exactly have we acquired? 




E_EXCESSIVE_DREYFUSS 
1 



Have we just acquired this year's re-imagining of a classic analog 
design object? Can a self-described working collection even make that 
accusation? 

The point is not to beat up on Nest or Henry Dreyfuss. They have 
each produced exceptional design objects in their own right. The point is 
to question how we choose to acquire objects and by those choices 
whether we've actually acquired anything at all. How many things that we 
call product design these days don't come with a software component? 
Even if that number is (x) today it is difficult to imagine that number not 
growing exponentially in the years to come. 

It is an especially difficult question to answer because no one 
would seriously suggest to Nest that they hand over the source code to a 



still nascent product that is actively competing with other offerings in the 
market place. Perhaps it suggests a role for archives and museums to act 
as a kind of trusted private escrow for things like source code and other 
intellectual property so that it may be preserved without forfeiting the 
opportunities of the present. It's certainly an interesting idea but we are 
busy trying to re-open a museum so that's about as far as we've gotten 
with that one. 




We also have one of the first-generation iPhones in our collection. 
The trouble with our iPhone is that we can't turn it on. I'm never entirely 
sure if the reason we can't turn it on is because the electronics are so old 
that they will short-circuit or simply because we've removed the battery so 
that it does not leak and damage other objects in our storage facility. 

In effect we have a remarkable example of industrial design and 
manufacturing prowess. Which it is. It really is. But can you meaningfully 
talk about an iPhone divorced from its software? Can you talk about an 
iPhone divorced of its interactions! 




I don't mean to set up a false dichotomy between hardware and 
software. It's not a challenge dance. The beauty of the iPhone is in the 
relationship between the hardware and the software. One of the things that 
I think gets overlooked too easily when we talk about the iPhone and its 
impact is that it made people sign -up for a monthly, and not always 
affordable, data-plan without so much as a second thought. 

Many of the features that the iPhone popularized had been 
available in other phones albeit not with the same level of polish or 
craftsmanship. And Apple certainly wasn't the first to see the possibility of 
a mobile device with a permanent connection to the Internet. It was 
though the first company to produce an object so desirable in its form 
(perhaps in its form alone) that people simply looked beyond their 
reluctance to purchase an earlier device with similar functionality. And 



because ol that we all experienced the so-called "network effort" both 
literally and figuratively. 

It may be that the inability for any object to be able to speak of its 
influence without a bespoke narrative is just the burden we all carry. I can 
accept that but as a cultural heritage institution it seems like our work, 
today, is to try a little harder to imagine how we might preserve systems 
as complex and sophisticated as the iPhone beyond simply sheilding their 
physical form from decay. 

This is the Newton MessagePad manufactured by Apple more than 
a decade before the iPhone was released. It was a complete flop in the 
marketplace. Using emulation 

Software http : / /www . imore . com/newton-os-running-iphone-ipad- 

einstein-emuiator you can run the Newton's software on your iPhone. 
So, I'll ask the question again: What exactly did we collect? 



This is a field in which 
one does one's work and 
it will be obsolete within 
10 years. 



This is the obligatory Steve Jobs quote but I think it's an important 
one. It's from an interview he did during the time he was running NeXT 
computer, in between the two periods he ran Apple. My sense listening to 
the interview is that he saw this as a sort of inevitable truth about 
computers and software that was ultimately liberating. That is 
understandable and it is a latitude we afford private enterprise. We have 
benefited enormously from that freedom not to have to slavishly honour 
the past. 



But sometimes confuse we inevitability with circumstance. 



In August of this year the Cooper-Hewitt acquired an iPad 
application called Planetary http://www.cooperhewitt.org/object- 

of -the-day/2013/ 08/2 6/planetary-collecting-and-preserving-code- 

living-object , created by a now-defunct company in San Francisco 
called Bloom. Planetary visualizes a user's music library as a series of 
celestial bodies. Songs are moons, albums are planets, artists are suns — 
and the orbits of each are determined by the length of albums and tracks. 
Their brightness represents their frequency of playback; songs and artists 
played less frequently than others drift further and further away, over 
time, from the planets or suns they orbit. Planetary is also a working 
music player and the time it takes for a moon to orbit a planet is governed 
by the length of the track that moon represents. 




Bloom was fond of telling people that it was creating a suite of 
"pop culture instruments" and that Planetary was just the first of many. At 
the time the company was launched Ben Cerveny, one of the founders, 
wrote: 



"We're building a series of bite-sized applications (instruments) 
that bring the richness of game interactions and the design values of 
motion graphics to the depth and breadth of social network activity, 
locative tools, and streaming media services. . . . These Bloom Instruments 
aren't merely games or graphics. They're new ways of seeing what's 
important. " 




What I like about the idea of these small bite-sized tools to 
visualize discrete problems, or sets of information, is that you see this idea 
popping up all over the place these days. Just think about the number of 
charts and graphs and other visualizations that are available to you every 
time you view your bank account online. Consider the amount of effort 
that goes in to trying to help you make sense of just your spending habits 
and then multiply that by the volume of information we are creating and 
leaving behind us like a shadow of the past keen to fill the vacuum of the 
present. 



Consider the NSA. 



This is a screenshot of one of the documents leaked by Edward 
Snowden listing some of the tools and filters that the agency has used to 
spy on, in this case, the French government. You can see the same 
motivation to filter - to extrude really - all this massive amount of data 
being collected in to a shape that can be more easily understood. 

HIGHLANDS, VAGRANT, LIFESAVER, BLACKHEART. The 
list goes on. 

These are the names of a symphony of instruments that the agency 
can play the same notes through to different effect and different meaning 
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Like all software, Planetary has been skirting obsolescence almost 
from the moment it was released. Software and hardware are separate but 
inescapable companions that exact a sometimes profound and warping, 
and sometimes destructive, influence on one another so we made a point 
of releasing the code for Planetary under an open source license. 

Three years since its first release, hardware and software 
environments comperable to the first iPad are available from a variety of 
sources. We are hopeful that people will think that Planetary is as 
interesting enough to consider porting the code to work on Android 
devices or in a web browser using WebGL or large interactive surfaces 
(which are increasingly indistinguishable from large desktop computers or 
increasingly internet-connected televisions). 



Planetary Extras /0 
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initial dump o! Planetary sock drawer 
initial dump ot Planetary sock drawer 
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initial dump Ot Planetary sock drawer 
initial dump ot Planetary sock drawer 
initial dump ot Planetary sock drawer 
initial dump ot Planetary sock drawer 



curatorial file (.git) 



Planetary Extras 



"Main highlights are probably : lots ot screenshots. a few glitches and out-takes, the website. Robert's original 
PSDs for many of the graphics in the app. the trailer video and Robert's "mood board" and PDF pitch for the 
app." - Tom Garden 



We also acquired both the history of changes to the software itself 
and many of the working files and other assets associated with the project. 
They form a kind of curatorial file for the object that, like the source code, 
can be downloaded and poked in a way that allows us collaborate with the 
general public without ceding our authority or our responsibility as 
stewards. 




When we announced the acquisition Seb wrote: 

"We liken this situation to that of a specimen in a zoo. In fact, 
given that the Smithsonian also runs the National Zoo, consider Planetary 
as akin to a panda. Planetary and other software like it are living objects. 
Their acquisition by the museum, does not and should not seal them in 
carbonite like Han Solo. Instead, their acquisition simply transfers them to 
a new home environment where they can be cared for out of the wild, and 
where their continued genetic preservation requires an active breeding 
program and community engagement and interest. Open sourcing the 
code is akin to a panda breeding program. If there is enough interest then 
we believe that Planetary's DNA will live on in other skin on other 
platforms. Of course we will preserve the original, but it will be 
'experienced' through its offspring." 




Because we did not acquire an iPad. We already have one of those 
and it suffers from all the same problems that the iPhone in our collection 
does. We acquired, instead, a piece of software that happened to run on an 
iPad. It is true that the original hardware absolutely informs the context 
that the work was created and experienced in but does that afford it a 
monopoly on our understanding of the application? 

Must we build, as Seb has called them, "period rooms" for every 
piece of software we acquire? Had Planetary been made to run on another 
device, by its original authors, would we have had to collect them all or 
choose just one? 




This is why we say the iPad was simply Planetary 's "then-best 
representation" when it was launched. When we talk about why we 
acquired Planetary we make sure to point out that as much as acquiring a 
piece of software, and using that as a way to work out how a museum 
continues to fulfill its mandate in a world gone digital, we have acquired a 
piece of interaction design. 




Open-sourcing Planetary was a deliberate preservation strategy on 
our part and an important part of that strategy was Bloom's CTO Tom 
Carden agreeing, for a time, to oversee and act as final arbiter of any bug 
fixes and updates and hopefully newer versions of the code that will allow 
the software - and more importantly the motive embodied in the 
application's interaction design - to live on beyond the iPad. Our hope is 
that Planetary will be the first of many digital acquisitions by the Cooper- 
Hewitt and one that will help us, and others, figure out how the museum 
might hold hands with the future-new. Or in Seb's words: "As we collect 
digital objects we change the institutions that are doing the collecting." 




And just in case everything else fails we printed out the source 
code on archival paper using the approved OCR-A font and it is stored in 
our collections warehouse along with all the other objects. 









thank you 








J 



Thank you. 



And yes, this really is in our 

Collection http://collection.cooperhewitt.org/objects/18382391/ 

Because... design? 
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Elsewhere #1384437600 

A ROOMBA sees the world in math 
"B" is for beta 



A ROOMBA sees the world in math 



This is a piece originally written for the Cooper-Hewitt Object of the Day 

blog http : //www. cooperhewitt .org/object-of -the-day/2013/12/06/roomba- 

sees-worid-math , and published on December 06, 2013. It is included here 
because OMG THIS IS THE STORY I WANT TO REMEMBER... 



Every home, it was promised in the 1960s, would have a robot butler. So far 
those sturdy and reliable companion robots of our imaginations have remained just 



that http://en.wikipedia.org/wiki/Replicant . And even as the technology to 

develop humanoid 

robots http://www.bostondynamics.com/robot_petman.html races ahead of US, 
in 2013, it has been the arrival of funny little disk-shaped and flattened UFOs 
circling our floors, picking up dust and other crumbs, that has defined home- 
automation in the early 21st century more than any other technology. 



Whereas other design museums began their robot collections with the Sony 

AibO http: / /www. powerhousemuseum. com/collection/database/ ?irn=8421 or 

automatons like the V&A's Tipu's 

Tiger http://www.vam. ac . uk/content/articles/t/tippoos-tiger/ the 

Cooper-Hewitt acquired its first robot in 2008 from iRobot, a 400-series Roomba 

Scheduler http : / /www . irobot . com/entry /scheduler . html vacuum cleaner. 

The Roomba has quickly become an important, and sometimes strangely 
meaningful, part of people's lives and whether it is looking for the 
art http://www.fiickr.com/groups/roomba/ in the mystery of its patterns or 
dressing them up http : / /www . myroombud . com/ itsalive . html or simply using 
them to put cats On them http: //www. youtube.com/watch?v=Of 2HU3LGdbo we 
see people investing these objects with 

personality http://gizmodo.com/5815879/how-to-give-robot-vacuums-a- 

personaiity-and-why-it-matters . We see them developing relationships (even 
if they are only in the minds of Roomba owners) and so today we are delighted to 
have a special guest writer for the Object of the Day blog post: 
©SelfAwareRoomba http://twitter.com/selfawareroomba . 



Since June 2012 

©SelfAwareRoomba http://twitter.com/selfawareroomba has been using 
Twitter as a platform for writing and thinking about Roombas and their role in our 
lives. Just as importantly it has been thinking our role — and the role of CAT 

FRIEND https : / /twitter . com/ Self AwareROOMBA/ status / 313366025137684480 

— in its life. Please join me in welcoming 

©SelfAwareRoomba http://twitter.com/selfawareroomba writing about ... 
well, itself http://collection.cooperhewitt.org/objects/18704235/ ! 



One part learner 

One part teacher 

To follow up on waste unadorned 

A blind bluesman 

Fills the room with color 

A ROOMBA sees the world in math 

And tries to rid you of you 

And the trail you left behind 

Plastic and vehicular 

Meticulous and lonely 

Hot for a charge 

Betrayed by a bunched up area rug 
Forlorn the broom and dustpan divorced 
Smite thee swiffer 
Jack of all trades 
Master of none 
Trapped here forever 
An object for some 
Gift of iRobot 




2013-12-06 



"B" is for beta 




This is a piece I wrote for the Cooper-Hewitt Labs 
blog http://labs.cooperhewitt.org/2013/b-is-for-beta/ , originally 
published on November 14, 2013. 

Without a whole lot of 

fanfare https://twitter.com/cooperhewittlab/status/4 01063311217012 736 
we released the "beta" version of the collections website, yesterday. The alpha 
version http://iabs.cooperhewitt.org/2012/iost-coiiection-aipha/ was 
released a little over a year ago and it was finally time to apply lessons learned and 
to reconsider some of the decisions that we made in the summer of 2012. 

At the time the alpha version was released it was designed around the idea 
that we didn't know what we wanted the site to be or, more importantly, what the 



site needed to be. We have always said that the collections website is meant to be a 
reflection of the overall direction the Cooper-Hewitt is heading as we re-imagine 
what a design museum might be in the 21st century. To that end the most important 
thing in 2012 was developing tools that could be changed and tweaked as 
quickly as 

possible http: //www. aaronland.info/weblog/20 12/1 1/09/ jello/#parallel- 
tms in order to prove and disprove ideas as they came up. 

The beta website is not a finished product but a bunch of little steps on the 
way to the larger brand redesign that is underway as I write this. One of those small 
steps is a clean(er) and modular visual design that not only highlights the objects in 
the collection but does so in a way that is adaptable to a variety of screens and 
devices. 

To that end, the first thing we did was to the object pages to make sure that 
the primary image for an object always appears above the fold. 

This is the first of many small changes that have been made, and that work, 
but that still need proper love and nurturing and spit and polish to make them feel 
like magic. In order to make the page load quickly we first load a small black and 
white 

version http: //images .collection.cooperhewitt.org/39391_4a0693cdc5269094 

of the object that serves as a placeholder. At the same we are fetching the small 
colour 

version http : / / images .collection. cooperhewitt . org/ 3 939 l_4a0 6 9 3cdc 52690 94 

as well as the the large ooh-shiny 

version http: //images .collection.cooperhewitt.org/39391_4a0693cdc5269094 

each replacing the other as your browser retrieves them from the Internet. 

Once the largest version has loaded it will re-size itself dynamically so that 
its full height is always visible in your browser window. All the metadata about the 
object is still available but it's just been pushed below the fold. 

Metadata is great http://www.businessweek.com/articies/2013-11- 

07/the-hidden-technology-that-makes-twitter-huge but. . . you know, giant 



pictures ! 



Maija Isola 

Finnish, 1927-2001 





We have 10 objects that Maija Isola has been involved with. See all of them. 



Maija Isola has had a hand in 1 0 objects that are part of our 
collection. Specifically: 10 objects as Designer. 

Maija Isola has been involved in work collected by the following 
departments: 10 objects from Textiles. 



Short URL http://cprhw.tt/p/2AvAi/ 

Person ID: 18049849 

Tag as: ch:person«18049849 

We're also pretty confident we know who Maija Isola 

Is at Freebase and Wikipedia. 



Maija Isola (born 15 March 1927 in Riihimaki. Finland, died 3 March 2001) was a leading Finnish designer of printed 
textiles. She also had a career as a visual artist. Life and career ... more. 



The second thing we did was standardize on square thumbnails for object list 

views. 



This was made possible by Micah's work calculating the Shannon entropy 
value for an image http: //labs .cooperhewitt.org/2013/defauit-sort-or- 
what-wouid-shannon-do/ . One way to think about Shannon entropy is as the 
measure of "activity" in an image and Micah applied that work to the problem of 
determining where the most-best place to crop a image might be. There's definitely 
some work and bug fixes that need to be done on the code but most of the time it is 



delightfully good at choosing an area to crop. 




As you move your mouse over the square 

version http : / / images . col lection . cooperhewitt . org/ 2 005 23 8bb2c5 2 4 3 0ca7 0 f 

we will replace it with the small thumbnail of the complete 

image http://images.collection.cooperhewitt.org/2 0052_38bb2c52430ca70f_i 

(and then replace it again with the square version when you mouse out). Thanks to 
Sha Hwang https://twitter.com/shashashasha for making a handy animated 
gif http: //gif pop. io/ of the process to illustrate things. 

Given the cacophony of (object) shapes and sizes in our collection 
standardizing on square thumbnails has some definite advantages when it comes to 
designing a layout. 

Although the code to calculate Shannon entropy httpa : //git-hub .oom/eoopcrhewit-t/ahannon aerver is available on 
our GitHub account the code to do the cropping is no! yet-. Hopefully we can fix that in the next week and we would 
welcome your hug fixes and suggestions for improving things. Update: Micah has made the repository for his panel-of- 
experts https : //github . com/cooperhewitt/panei-of -experts code which includes the crop-by-Shannoii-entropy stuff public 
and promises that a blog post will follow, shortly. 



mmmmmm pretty ! 

It is worth noting that our approach owes a debt of inspiration and gratitude 
to the work that The Rijksmuseum https://www.rijksmuseum.nl/ has done 
around their own collections website. Above and beyond their efforts to produce 
high quality digital reproductions of their collection objects and then freely share 
them with their audiences under a Creative 

Commons https : / /www. ri jksmuseum.nl /en/api/terms-and-conditions-of- 

use license they also chose to display those works by emphasizing the details of a 
painting or drawing (or sculpture) rather than zooming further and further back, 
literally and conceptually, in order to display the entirety of an object. 

You can, of course, still see an object in its totality but by being willing to 
lead with a close-up and having the faith that users will explore and consider the 
details (that's sort of the point. . . right?) it opens up a whole other world of 
possibilities in how that information is organized and presented. So, thanks 
Rijksmuseum! 




In addition to updating the page listing all the images for an object to use 
square thumbnails we've also made it possible to link to the main object page (the 
one with all the metadata) using one of those alternate images. 



For example the URL for the "The Communists and The Capitalists" chess 

set is 

http://collection.cooperhewitt.org/objects/18647699/ http : / /collection . cooper] 
and by default it displays an image of all the chess pieces lined up as if on a chess 
board. If you wanted to link to the chess set but instead display the photo of the 
handsome chap all dressed up in gold and jodhpurs you would simply link to 
http://collection.cooperhewitt.org/objects/18647699/with-image- 

12603/ http: //collection. cooperhewitt.org/objects/ 1864 7 699 /with-image- 
12603/ . 

The images themselves (on the object images 

page http://collection.cooperhewitt.org/objects/18647699/images/ ) all 

point to their respective with-image-IMAGEID links so just right click on an 
image to save its permalink. 




Book CtKM. ■Bookiackm by Alvin Lustig tor 1 Three Tales' 
by Flaubert. New Lithography in (an ana black ink oh on- 
white shiny wove paper Gift of Tama' Cohen and Dave 
SI a; off 1993-31-165-4 

Then are I people M I rules are associated wrth ttis ooieci 
AJv.n Luatig » rote was W Designer. Dtmo. This ob|ect rs 

part of Drawings. Prims and Graphic Design collection 



Book Crj»« "Metropolitan Lcs Angeles: One Community by 
Me) Scott* 1901-50 Paper. Gil ot Susan Luang Peck 
8»1 -»» 

There Is one person is associated with this object Alvin 
Lustig s role was as Graphic Designer This object is part of 

Drawings Punts . and Graphic Design collection 



Book Cover 'BcBk|acket by Alvin Lusbg tor 'Rowers 01 
Evil' by Charles Lithography in tan and purple ink on on- 
white wove paper Gilt o* Tamar Cohen and Dave Sato" 
1993-31 -165 -B 

There are ? people in I rules are associated with this obieci 
Alvin Luahg's role was as Designer, Donor This object is 

part of Drawings, Prints, and Graphic Design collection. 



On most desktop and laptop displays these square list views end up being 
displayed three to a row which presents many lovely opportunity for surprising and 
unexpected "haystack 

triptychs http : / /www . aaronland . inf o/weblog/20 12 / 04 /02 /haystack/#parallel- 



ogram 



Or even narrative http : / /metascott . com/the-narrative-and- 
collaborative-gutter-of-transmedia/ ... almost. 





In the process of moving from alpha to beta it's possible that we may have 
broken a few things (please let us 

know https : //twitter. com/cooperhewittlab/ if you find anything!) but one 
of the things I wanted to make sure continued to work was the ability to print a 
properly formatted version http: //labs. cooperhewitt.org/2013/cmd-p/ of 
an object page. 



We spend so much time wrestling with the pain around designing for small 
screens and big screens and all the screens in 

between http://frankchimero.com/what-screens-want/ (I'll get to that in a 
minute) that we often forget about paper. 




Lots of people have perfectly good reasons for printing out information from 
our collection so we would like that experience to be as simple and elegant as the 
rest of the site. We would like for it to be something that people can take for granted 
before even knowing it was something they needed. 

You can print any page obviously but the print-y magic is really only 
available for object and person pages, right now. Given that the alpha site only 
supported object pages this still feels like progress. 





Finally, mobile. 



Optimizing for not-your-laptop is absolutely one of the things that was not 
part of the alpha collections website. It was a conscious decision and, I think, the 



right one. Accounting for all those devices — and that really means all those view 

ports http: //www. quirksmode.org/blog/archives/2013/ll/of_viewports_an.htr 

— is hard and tedious work where the rewards are short-lived assuming you live 
long enough to even see them. So we punted and that freed us up to think about the 
all the other things we needed to do. 

But it is also true that if you make anything for the web that people start to 
enjoy they will want to start enjoying it on their phones and all the other tiny 
screens connected to the Internet that they carry around, these days. So I take it as 
some small measure of success that we reached a point where planning and 
designing for "mobile" became a priority. 




Which means that, like a lot of other people, we used 

Bootstrap http://getbootstrap.com/ . 

Bootstrap is not without its quirks but the demands that it places on a 



website are minimal. More importantly the few demands it does place are negligible 
compared to the pain of accounting for the seemingly infinite and not-in-a-good- 
way possibility jelly http : / /magicalnihilism . com/ 2009/02/18 /exporting-the- 
past-into-the-future-or-the-possibility- jelly-lives-on-the- 
hypersurf ace-of-the-present/ of browser rendering engines and device 
constraints. 

The nice folks at Twitter http : / /www . twitter . com/ had to figure this 
out for themselves. I choose to believe that they gave their work back to the Internet 
as a gift and because there is no glory in forcing other people to suffer the same pain 
you did. We all have better things to do with our time, like working on actual 
features. So, thanks Twitter! 

We're still working out the kinks using the collections website on a phone or 
a tablet and I expect that will continue for a while. A big part of the exercise going 
from alpha to beta was putting the scaffolding in place where we can iterate on the 
problem of designing a collections website that works equally well on a 4-inch 
screen as it does on a 55-inch screen. To give us a surface area that will afford us 
another year of focusing on the things we need to pay attention to rather always 
looking over our shoulders for a herd of thundering yaks demanding to be 

Shaved http://en.wiktionary.org/wiki/yak_shaving . 
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collection.cooperhewitt.org C 




Welcome to the beta release of 
our new collection database! 

This is our stuff, wg hav© lots of it 




A few known-knowns, in closing: 

• IE 9 — there are some problems with lists and the navigation menus. 
We 're working on it. 

• The navigation menu on not - y our - laptop devices needs some love. Now 
that it's live we don't really have any choice but to make it better so 
that's a kind of silver lining. Right? 

• Search (in the navbar). Aside from there just being too many options 
you can't fill out the form and simply hit return. This is not a feature. It 
appears that I am going to have dig in to Bootstrap 's Javascript code 
and wrestle it for control of the enter key as the first press opens the 
search drop-down menu and the second one closes it. Or we '11 just do 
away with a scoped search box in the navigation menu. If anyone out 
there has solved this problem though, I'd love to know how you did it. 

• Square thumbnails and mouseover events on touch devices. What 
mouseover events, right? Yeah, that. 

• There are still a small set of images that don't have square or black 
and white thumbnails. Those are in the process of the being generated 
so it's a problem that will fade away over time (and quickly too, we 
hope). 

Enjoy! http: //collection. cooperhewitt.org/ 



2013-11-14 



history demands renumeration 

much history so remember 
privatesquare two dot oh 



much history so remember 



wow ideation 




This is the story I want to remember. See 

also: https : / /twitter . com/cooperhewitt lab/ status /4 1 3698548677349377 

and see also- 

er https://twitter.com/thisisaaronland/status/414178618399420417/ 
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privatesquare "two dot oh" 



privatesquare php *s2 u 9 

privatesquare is a simple web application to record and manage a database of foursquare check-ins. 

Last updated 28 minutos ago 



There's a new version of 

privatesquare https : //github . com/ straup/privatesquare /releases /tag/v2 .01 

I guess it's safe to call it version "two dot oh". It is sufficiently different and 
sufficiently backwards incompatible with earlier versions that I created a snapshot 
of the project's first two-years worth of work and called it version 

1.0 https://github.com/straup/privatesquare/releases/tag/vl-0 

Installing privatesquare from scratch is pretty much the same as always but 
upgrading an existing installation is a thing that will demand some time and 

attention https : / /github. com/ straup/privatesquare /blob/master /CHANGES .md# 

It's not ideal but privatesquare remains a mornings-and-weekends project. 

Upgrading requires attention because there are some pretty fundamental 
changes to the underlying database structure. The changes mean that it's now 
possible to check-in to other kinds of places that aren't Foursquare venues. As of 
this writing you can check-in to three other types of places. 



this is privatesquare = 










// / 7 






f ^2, 

l / .//A 












in a car 


1 


> Done 




on a boat 
in transit 




wish you were here 


kill me now 

so confused 





The first is a canned list of funny-haha "states of mind" like "on a bike" 
or "on a plane" or "on a telco" or "kill me now". I say funny-haha because on the 
surface it just seems sort of silly but is actually really useful. It's a fixed list and the 
criteria for what get's included is pretty arbitrary. At the moment it's very much 
biased towards modes of travel and office 

life https : //github . com/ straup/privatesquare /blob/master /www/ include/ lib 

but both are situations which often demand a kind of non-specific outlet, whether 
it's in the moment or in the re-telling. 



function vcnucs_statoofmind_vcnucs ( ){ 
Svenues ■ arrayf 



array.; ' id ' 


=> 


'51783653' r 


' name ' 


=> 


'in 


a car ' ) , 


array ( 1 id ' 


=> 


'51783655' , 


' name ' 


=> 


' in 


a cab ' ) , 


array ( id 




'52204087', 


'name ' 


=> 


1 on 


a bike ' ) , 


array. 1 id ' 


=> 


'51783657' , 


' name ' 


= > 


1 on 


a plane 1 ) , 


array ( 1 id 


=> 


'51783659* , 


' name ' 




1 on 


a train' ) , 


array; 1 id ' 


=> 


'51783661' , 


' name ' 




1 on 


a boat ' ) , 


array ( ' id ' 


=> 


'52204085' , 


' name ' 


= > 


' on 


the water ' ) , 


array ( id 


> 


'51866911', 


' name ' 




1 in 


transit ' ) , 


array( 1 id ' 


=> 


'68234601 ' , 


' name ' 


=> 


1 in 


a meeting ' ) , 


array{ 1 id 


=> 


'68234603 ' , 


' name ' 




1 on 


a telco' ) , 


array; 1 id ' 


=> 


'52204033' , 


' name ' 


= > 


'wish you were here') 


array ( ' id ' 


=> 


'52204035' , 


' name ' 


= > 


' kill me now' ) r 


array ( id 




'52204045' , 


' name ' 




' EXTERMINATE I Ml'), 


array ( 1 id ' 


=> 


'51866909', 


' name ' 




1 DO 


confused ' ) , 



); 

return Svenues; 

> 



Just in case you still thought artisanal 
integers http://www.brooklynintegers.com/ were a joke... 

Second, people now have the ability to create and check-in to "user- 
defined" places. This is basically what it sounds like. I could have just written a 
bespoke interface to add things to Foursquare via their API but like the original 
motivation for writing privatesquare there are always going to be places that you 
don't necessarily want to share with strangers or a third-party service. It is 
aggressively simple, partly because I wondered how quickly I could add it to this 
round of changes (after getting "states of mind" working) without it ballooning in to 
a sinkhole of feature creep. 

User-defined places have names and nothing else, yet. You can choose to 
check-in to a place at the time it's created but that's about it. The other notable 
feature, which user-defined places share with "states of mind" is that they may not 
have fixed geographies. Just think about being able to check in to "hungover" for a 



minute and you can see the attraction of this feature. It's not required but it is 
possible. 



this is privatesquare 




Breakfast 
This place has a fixed location O 
Check-in to this place Q 



MAKE IT SO 



It's not possible to share user-defined places yet and it probably won't be for 
a while. Back in the Flickr days we used to talk about user-defined places a lot. We 
never did anything about it but that was only because of organizational minutiae and 
a lack of time. All the geo place-based stuff was built using the Where On Earth 
(WOE) gazetteer packaged up as an an enormous (like 12GB by the time I left) 

"data pack" https:/ /archive. org/search.php?query=geoplanet which was 

then poked and prodded by an HTTP interface. This is where WOE 
IDs http://woe.spum.org/ came from. 

I always hoped that we could supplement the data pack approach in two 
ways. First, I wanted to be able to create new data packs specific to a service (where 
service means a thing that people used, like Flickr or Upcoming or Yahoo Autos) 
and the ability to pair them with the master data pack and to then weight the results 



for the associate data services (like geocoding) by source. Second, I wanted to be 
able to bias geographic results using a ranked list of data sources or providers which 
in Flickr's case would have inevitably meant user-defined places. The closest we 
ever got to this were the flickr. people. geoBookmarks API methods but 
they never got the attention they deserved and were sort of stillborn from the 
moment they were released. 

I suppose I could (will have to... ?) add photo sharing to privatesquare but in 
the meantime most of the "pipe" has been laid to start doing all the yummy things 
around user-defined 

places http: //www. aaronland.info/weblog/2 012/02 / 14 /incentivize/#headless 
that we never did at Flickr. 

As an aside, one of the interesting things about creating venues that don't 
have fixed geographies is that it's not hard to start thinking about privatesquare as a 
kind of Dotspotting http : / /www . dotspotting .org/ client. One of the early 
design decisions with Dotspotting was that it be a document-based system which 
means it's never been possible to update a 

sheet http://www.dotspotting.org/faq/ once it's been uploaded in to the site. 
Variable geography check-ins in privatesquare don't actually solve this problem but 
you could imagine using privatesquare to create a user-defined place (for example 

Eric's COlOUred-dotS-On-drainS http : / /www . pbs . org/ idealab/2 0 1 1 / 03 /how- 
dot spotting-began-with-colored-dots-on-drains-in-san-f rancisco06 6 

collection) and doing all your collection over time and then exporting it as a CSV 
file in to Dotspotting at the end. Between user-defined places and a proper public- 
facing API (more on that below) the number of places that privatesquare and 
Dotspotting could finally be made to hold 

hands http : / /near f uturelaboratory . com/ 2012/01/22 /privatesquare / is 
actually pretty exciting but there are enough other things going on right now that I 
will just have to look at that place longingly for the moment. The possibilities are 
delicious to think about, though. 



e o o 



private square 

(^) ^ privates qua^/ny pi 



LLL 



privatesquare 
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this is privatesquare 




29 WEST 42 STREET 



• 



i was there 



• 



don't tell foursquare 



• 



THIS HAPPENED 



Finally, it's possible to check in to buildings from the New York Public 

Library's 1852 Perr is Atlas http://www.aaronland.info/nypl-perris/ .This 
is a feature that was started way back in the summer during the NYPL's Maps 
Hack workshop http : / /www . nypl . org/blog/ 2 013/07 / 12 /maphack-hacking- 
nycs-past-nypi-iabs-f riends and which then got steamrollered by the rest of 
life. It's not really of much use to anyone outside of New York City and even for 
those people who live it's not entirely clear how or why you'd use it. The API used 
to look up buildings is (I think) not completely worked out and it doesn't completely 
map to the idea of venues or check-ins so in that way it's sort of like a proof-of- 
concept or reference implementation that's been pushed in to the spotlight without 
having had time to put its pants on. 



But who cares! It's working code that proves it can be done. The code now 
supports four distinct types of places you can check-in to and while none of it is 
very elegant (or documented anywhere yet) it does work. It means that it's possible 
to think about adding support for other things. It's possible to think about a way to 



check-in to the 37, 000 works of art at MoMA (not a metaphor). It means that, with 
a bit of work, it ought to be possible to rebuild the Upcoming.org 

database http://waxy.org/2013/04/the _death_of_upcomingorg/ from the 
Archive Team rescue https : / /archive. or g/details/archiveteam_upcoming 
and use that a source for venues. Or, going back to the NYPL buildings, imagine 
using the Library of Congress' historical 

gazetteer https : //archive. org/details/sotmus2013-Schuyler_Erle_- 
_A_Gazetteer_for_the_Library_of_Congress-68099833 (which isn't yet public 
so far as I know) as a check- in source. 

"/ was there ", indeed. 



Amsterdam, NH, 
Netherlands 




on a bike 

you've been her-:- 6 times 




All of which feels like progress to me and a nice place to stop for a while 
and let things settle down, privatesquare remains a thing that you build and install 
yourself. This is not the service-for-strangers that I am ready or want to run yet. The 



code and the installation (or upgrade) 

instructions https : // github.com/straup/privatesquare/blob/master /CHANGES .) 

are available on the GitHubs, over here: 

https://github.com/straup/privatesquare/ 

Things that got finished. 

• You can check-in to "states of mind". 

• You can create your own custom places which may or may not have 
fixed geographies. 

• You can check-in to historic buildings in New York City. 

• All of the templates and stylesheets were updated to use 

Bootstrap http://getbootstrap.com/ 3.0. On the subject of things 
like Bootstrap John Allsop's blog post The Other Web We 

Lost http: //www.webdirections . org/blog/the-other-web-we- 

lost/ , about the slippery slope of frameworks , is worth reading. I am 
not sure that I am as suspicious of things that ultimately boil down to 
HTML + CSS + JavaScript ( which is already a moon language so it's 
hard to make it any weirder...) but he raises some valid points. When it 
comes to using Bootstrap, though, I can only say the same things I said 
at the end of the blog post about the beta release of the Cooper-Hewitt 
collection 

website http : / /www . aaronland . inf o/weblog/ 2 013/11/14 /things /#beta 

• A bunch of experimental features were 

removed https : //github.com/straup/privatesquare/blob/master/CHAN 

since they either weren't being actively developed or didn't actually 
work very well. 



Things that I didn't quite finish. 



• Exporting a series of check-ins as an iCalfile. The code is all there but 
I appear to be generating invalid calendar documents. I thought I could 
get this working on a couple of long-haul flights but that didn't happen 
so I'm just going to set this aside for the time being and let it be a tiny 
release of its own. 

That that didn't get addressed at all. 

• Timezones. OMGWTFTZ... timezones. I so desperately have to fix this. 
I know this is what I said the last 

time http://nearfuturelaboratory.com/2 012/09/04/the-atlas- 

of-desire/ and I haven't done anything about it. This ought to be 
pretty straightforward to do for Foursquare check-ins since a venue's 
timezone is typically returned with the metadata for that venue. For the 
other place types it gets a little more complicated. On the one hand it's 
not complicated at all. I could simply load the whereonearth- 

timezone https : //github.com/straup/whereonearth-timezone 

dataset in to Matt Biddulph's handy reverse 

geOCOder https://github.com/mattb/flickrgeocoder-java and 

call that for every not-Foursquare check-in. The problem with this 
approach is that privatesquare has always tried to follow the rule that 
the Dotspotting http://www.dotspotting.org/ project set for 
itself: That it be possible to install and run on the plainest of vanilla 
web-hosting services. This actually introduced a world of (still) never- 
ending pain from a development point of view but the hope was that we 
could build a genuinely useful tool without the burden (or cutting edge) 
of this week's dependency chain. Which pretty much rules out long- 
running Java daemons. Geonames has a handy reverse geocoding 

timezone API http: //www. geonames . org/export/web- 
services . html#timezone so that's a possibility. The number of 
timezones, though, is finite and so there's probably a way to filter the 
number of actual possibilities down to a manageable level using simple 
point-in-bounding -box queries and then final checking doing point-in- 
polygon queries with simplified shapefiles, keeping the whole thing in 
the local database and application code. That's what I am thinking on a 
Saturday morning, anyway... 



A proper public facing API, which really means folding in all the work 
from flamework-api https://github.com/straup/flamework-api . 
This also means moving privatesquare over to using HTTPS exclusively 
because... grumble grumble, OAuthl. One of these days I will get 
around to writing the Epic Rant about the piss-poor state and 
delusional pony-thinking that surrounds delegated authentication but 
today is not that day. One of the problems with using OAuthl is that is 
introduces a massive chunk of bloat and burden in to the dependency 
chain (see above). It's not that SSL is bad or wrong. It is plain as day 
that it's the correct thing to do. In principle. In practice, if s fiddly and 
confusing and potentially expensive depending on who you're using as 
a certificate authority or hosting provider. So, a proper public facing 
API is coming but only once I make sure that the code to support it can 
be used to replicate the same not-really-secure private API hooks that 
the site already uses. 

Things that come next, pretty much in this order. 

Timezones. For all the reasons mentioned above, this has to be the next 
serious chunk of work. If only to make iCal export not completely 
stupid and to make it possible to add trips. Trips? 

"Trips", aka Dopplr-mode . I'm not sure what this will look like yet. It's 
not going to be a complete Dopplr clone but to the extent that I had to 
get out my laptop and check the site during my clearance interview for 
Government Club in order to remember why I went to Canada in the 
summer of 2007 it feels like functionality that needs to be added, in 
light ofDopplr's recent 

demise http://magicalnihilism.com/2013/ll/04/bye-dopplr/ . 

A public-facing API. See above. 

Profit? 

Things that happened between then and now. 



• Apparently, Foursquare removed the ability to add private check- 
ins https://twitter.com/blacktar/status/408 67864 02 4 3982 33 7 

/ haven't had a chance to confirm whether this means you can't check 
in "off the grid" or whether it means that you can no longer scope 
check-ins to only followers or what. So I bet there are some API calls 
which privatesquare makes that will fail... 



Good times. 



on a plane 

John F KermeoV Inf I A 









John F k.-ij.tv tut: 


1 



You were here on Friday. November 29. 2013 at 
14:15. H was 2° C and partly cloudy. permalink 



Airport Bar 

John F Kennedy Int'l Airport. United States 




2013-12-07 




Things I Have Written About 
Elsewhere #1387728417 

Rijkscolors! 

"C" is for Chromecast: hacking digital signage 



Rijkscolors! 



Objects in the shade of 

We have 132 objects that overlap with this color and this is page 2 of 6 

The closest color to #fefdc8 is lemon chiffon which in robot-speak is #fffacd 




Mate-sate wood Gift of Stephen W Brenar and Carol B 
Brm 1978-146-73 

Tho object is part of Product Design and Decorative Arts 



■Lodewiit Kill (1 601 -43). toning van Frankrijk 1 MMH 

This obtect ia part of the tli)Ksnusei.m collection. It unot 
part of the Cooper- Hewitt's collection and you re seeing it 
here because you've enabled the experimental RMkacotor 



Poster, "Latere! Museum Har«uKu-, 3000 Oft -set lithograph 
on white wove paper. Gitt of Sara and Marc Benda. 
200B-12-1B 

TNa Obtect is pad of Drawings, Prints, and Graphic Design 
collection. There are ? images of this obtect 



This is a piece originally written for the Cooper-Hewitt Labs 

blog http : / /labs . cooperhewitt . org/2 0 13 /rijkscolors-or-colorific- 

promiscuity/ , and published on December 11, 2013. 

Rijkscolors are an experimental feature that allow you to browse not only 
images from the Cooper- Hewitt's collection but also images from the 
Rijksmuseum https://www.rijksmusetim.nl/en by color! 

We see this as one way to start to work through the age-old problem of 
browsing collections across multiple institutions. Not everyone arrives at the 
Cooper-Hewitt (or the Rijksmuseum) with an expert knowledge of our curatorial 
and collecting history and the sheer volume of "stuff available can be 
overwhelming. Everyone, at some point, has the "Explore" 

problem http://code.flickr.net/2 009/03/03/panda-tuesday-the-history- 
of-the-panda-new-apis-explore-and-you/ : It's the point where you have SO 



much good stuff to share with people but no good (or many sort-of-bad) avenues for 
letting people know about it. 

Color is an intuitive, comfortable and friendly way to let people warm up to 
the breadth and depth of our collections. Since adding the ability to search the 
Collection by Color http://collection.cooperhewitt.net/objects/colors/ 
it's quickly become the primary way that people browse our collection (more on 
that below) and as such feels like an excellent tool for browsing across collections. 




■Kom urt V.O.C. -setup do Wtto Leouw ' 
NG-197B-1S7-101S-W 

Tho object is part of Via Riiksfuwum collection It is not 
part of tha Cooper- Hewitt s collection and you're seeing it 
here because you've enabled tha eioe- t-cmi Ri|kscolor 



Bandbox, 'Wakng Beam Stdewnoelar' . ca 1B40 Block- 
printed paper on pasteboard support. Gil o' Mrs. Frederick 
F Thompson. 1fl13-4S-B-a.b 

Tha object is part ot Walcovamga cdlactkxi. 



Figure. 'SokJwr Seated mUi Rflo' ca 1 970 Porcelain 
{bisque) The Henry and Ludmilla Shapiro Coleebon; Partial 
gift and partial purchase.. 1080-41-203 

This object was made by .omonoeov Porcelain Factory. 
This object is part of Product Design and Decorative Arts 
collection 



Over time, we hope to add this functionality for many other cultural heritage 
institutions but chose to start with the Rijksmuseum because we share an historical 
focus in our early collecting practices and because they were nice (read: 

AWESOME http : / / collection . cooper hewitt . org/ images /cooper spanktumbli 

enough to make all their collection images available under a liberal Creative 
Commons license https : / /www. rijksmuseum. nl/en/api/ terms-and- 
conditions-of-use . 

We then indexed all those images using the same tools we use to extract 
colors http://iabs.cooperhewitt.org/2013/giv-do/ and measure busy-ness 



Or "entropy" http://labs.cooperhewitt.org/2013/default-sort-or-what- 

wouid-shannon-do/ from our own collection and combined the two lists. Images 
from the Rijksmuseum have a different colored border to indicate that they are not 
part of our collection. Images from the Rijksmuseum link directly to the page for 
that object on the Rijksmuseum website https://www.rijksmuseum.nl/en 
itself. 




■■■■ ■■■ ■■■ 

t t t 

Cooper-Hewitt Cooper-Hewitt Rijksmuseum 



As with the concordances for 

people http://labs.cooperhewitt.org/2013/first/ we just want to hold 

hands (for now — Seb tells me this means we might want to move to second 
base http: //www. smh.com.au/articles/2 004/02/09/ 1076 175089032 .html in 
the future) with other museums and are happy to send visitors their way. After all, 
that's what the Internet is for! 

Rijkscolors is an experimental feature so you'll need to enable it on a per- 
browser basis by visiting the experimental 

features http://collection.cooperhewitt.org/experimental/ section of the 

collection website, here: 

http://collection.cooperhewitt.Org/experimental/#rijkscolors 



But wait, there's more. 



We've also made public all the code used to harvest metadata and images 
from the Rijksmuseum as well as the resultant data dumps mapping colors and 
entropy scores to Rijksmuseum accession numbers with internal Cooper-Hewitt 
object IDs http : / /www . brookiyninteger s . com/ . We created a custom mapping 
because we use Solr to do color search on the website and that requires a numeric 
ID as the primary key for an object. 

Then we imported all the objects from the Rijksmuseum, along with their 
color values and other metrics, in to our Solr index giving them a magic 
department ID http : / /collection . cooperhewitt . org/departments / (aka 
51949951 or the Rijksmuseum) and making them private by default. If you've 
enabled Riskscolors when we search for objects by color instead of only asking for 
things with a given color that are public we ask for things that are public OR part of 
department number 5 194995 1 . Simple! 

The code and the data dumps are provided as-is, more of a reference 
implementation and a toolbox than anything you might use without modifications. 
We've put it all on GitHub and we welcome your suggestions and fixes: 

https://github.com/cooperhewitt/rijksmuseum-collection/ 



We mentioned search vs browse so let's take a peek at the last 30 days (Nov 
1 1 to Dec 10, 2013) of visitor behaviour on the collection site. 



■ New Visitor ■ Returning Visitor 
Colors (excluding SI) Random (excluding SI) 




Search (excluding SI) Fancy search (excluding SI) 




Or put another way: 

• 48.89% of visits used color navigation (anywhere - not just color 
palette page) 

• 4.39% of visits used normal search 

• 224% of visits used random button 

• 1.25% of visits used fancy search 

The figures for color navigation are artificially inflated by the press the 
feature got in 

Slate http : //www. slate . com/blogs/theeye/2 0 13/1 l/19/smithsonian_cooper_h( 

The Verge http://www.theverge.com/2013/11/21/5129062/browse-the- 

smithsonian-cooper-hewitt-museum-with-colors and elsewhere (the comments 
are amusing), but even removing that spike, color navigation is at least twice as 



used as search in the time period. We'll report back on some new data once 
December and January are done. 



Pages / Visit 

Colors (excluding SI) 

7.10 


Avg. Visit Duration 

Colors (excluding SI) 

00:03:10 




Random (excluding SI) 

22.70 


Random (excluding SI) 

00:08:52 


Search (excluding SI) 

21.25 


Search (excluding SI) 

00:10:42 


Fancy search (excluding ... 

29.10 


Fancy search (excluding ... 

00:14:23 









Not unsurprisingly, visitors who use search spend a lot more time on the site 
and look at many more pages. They are also far more likely to be returning visitors. 
For newbies, though, color and random navigation methods are far more popular - 
and still result in healthy browsing depths. 



In related news Nate Solas http://natesoias.com/ sent us a patch for 
the palette-Server https://github.com/cooperhewitt/palette-server/ , the 
tool we use to extract colors from our collection imagery. He said: 

". . .this improves the color detection by making it a bit more human. It goes 
two ways: 1 ) boost all color "areas" by saturation, as if saturated colors take up 
more room in the image. 2) add a "magic" color if a few conditions are met: not 
already included, more than 2x the average image saturation, and above the 
minimum area for inclusion." 



palette-server debug 




We've now merged Nate's 

changes https://github.eom/cooperhewitt/paiette-server/puii/2 in to our 
code base (technically it's actually a change to Giv's 

RoyGBiv https://github.com/givp/RoyGBiv code) and they will be applied 
the next time we run the color-extraction tools on our collection (and the 
Rijksmuseum's collection). Thanks, Nate! 

As with all the experimental features they are . . . well, experimental. They 
are a little rough around the edges and we may not have found (or even noticed) any 
outstanding problems or bugs. We hope that you'll let us 

know https://twitter.com/cooperhewittiab/ if you find any and otherwise 
enjoy following along as we figure out where we're going, even if we're not always 
sure how we get there. 
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"C" is for Chromecast: hacking 
digital signage 



This is a piece originally written for the Cooper-Hewitt Labs 

blog http : //labs . cooperhewitt . org/ 2 0 13 /c-is-f or-chromecast-hacking- 

digitai-signage/ , and published on December 9, 2013. 

Since the late 1990s museums have been fighting a pointless war against the 
consumerization of technology. By the time the Playstation 2 was released in 2000, 
every science museum's exhibition kiosk game looked, felt, and was, terribly out 
dated. The visitors had better hardware in their lounge rooms than museums could 
ever hope to have. And ever since the first iPhone hit the shelves in 2007, visitors to 
museums have also carried far better computing hardware in their pockets. 

But what if that consumer hardware, ever dropping in price, could be 
adapted and quickly integrated into the museum itself? 

With this in mind the Labs team took a look at the $35 Google 

Chromecast http: / /www. google . com/intl/en/chrome/devices/chromecast/ 

- a wifi-enabled, HDMI-connected networked media streaming playback system 
about the size of a USB key. 

With new media-rich galleries being built at the museum and power and 
network ports in a historic building at a premium, We asked ourselves "could a 
Chromecast be used to deliver the functionality of digital signage system, but at the 
fraction of the cost"? Could some code be written to serve our needs and possibly 



those of thousands of small museums around the world as well? 




Before we begin, let's get some terms of reference and vocabulary out of the 
way. The first four are pretty straightforward: 

• Display - A TV or a monitor with an HDMI port. 

• Chromecast device - Sometimes called the "dongle". The plastic thing 
that comes in a box and which you plug in to your monitor or display. 

• Chromecast application - This is a native application that you 
download from Google and which is used to pair the Chromecast 
device with your Wifi network. 

• Chrome and Chromecast extension - The Chrome web browser with 
the Chromecast extension installed. 



That's the most basic setup. Once all of those pieces are configured you can 
"throw" any webpage running in Chrome with the Chromecast extension on to the 
display with the Chromecast device. Here's a picture of Dan Catt's 
Flambientcam https: //github.com/revdancatt/CAT436-f lambientcam being 
thrown on to a small 7-inch display on my desk: 




Okay! The next two terms of reference aren't really that complicated, but 
their names are more conceptual than specific identifiers: 

The "Sender" - This is a webpage that you load in Chrome and which can 
cause a custom web page/application (often called the "receiver", but more on that 
below) to be loaded on to one or more the Chromecast device via a shared API. 

The "Receiver" - This is also a webpage but more specifically it needs to 
be a living breathing URL somewhere on the same Internet that is shared by and can 
be loaded by a Chromecast device. And not just any URL can be loaded either. You 



need to have the URL in question whitelisted by Google. Once the URL has been 
approved you will be issued an application ID. That ID needs to be included in a 
little bit of Javascript in both the "sender" and the "receiver". 

There are a couple important things to keep in mind: 

• First, the "sender" application has super powers. It also needs to run 
on a machine with a running web browser and, more specifically, that 
web browser is the one with the super powers since it can send 
anything to any of the "displays" . So that pretty much means a 
dedicated machine that sits quietly in a locked room. The "sender" is 
just a plain vanilla webpage with some magic Google Javascript but 
that's it. 

• Second, the "receiver" is a webpage that is being rendered on/by the 
Chromecast device. When you "throw" a webpage to a Chromecast 
device (like the picture of Dan's Flambientcam above) the Chromecast 
extension is simply beaming the contents of the browser window to the 
display, by way of the Chromecast device, rather than causing the 
device to fetch and process data locally. 

Since there's no more way to talk at this webpage (the "sender") because it's 
running in a browser window that means we need a bridging server or a. . . "broker" 
which will relay communications between the webpage and other applications. You 
may be wondering "Wait. . . talk at the sender" or "Wait. . . other applications? " or 
just plain "...What?" 

Don't worry about that. It may seem strange and confusing but that's 
because we haven't told you exactly what we're trying to do yet! 

We're trying to do something like this: 



We're trying to imagine a system where one dedicated machine running 
Chrome and the Chromecast extension that is configured to send messages and 
custom URLs for a variety of museum signage purposes to any number of displays 
throughout the museum. Additionally we want to allow a variety of standalone 
"clients" in such a way that they can receive information about what is being 
displayed on a given display and to send updates. 

We want the front-of-house staff to be able to update the signage from 
anywhere in the museum using nothing more complicated than the web browser on 
their phone and we want the back-of-house staff to be able to create new content 
(sic) for those displays with nothing more complicated than a webpage. 

That means we have a couple more names of things to keep track of: 

The Broker - This is a simple socketio server http://socket.io -a 
simple to use and elegant server that allows you do real-time communications 



between two or more parties - that both the "sender" and all the "clients" connect 
to. It is what allows the two to communicate with each other. It might be running on 
the same machine as a the Chrome browser or not. The socket.io server needn't 
even be in the museum itself. Depending on how your network and your network 
security is configured you could even run this server off site. 

The Client - This is a super simple webpage that contains not much more 
than some Javascript code to connect to a "broker" and ask it for the list of available 
displays and available "screens" (things which can shown on a display) and controls 
for setting or updating a given display. 

In the end you have a model where: 

• Some things are definitely in the museum (displays, Chromecast 
devices, the browser that loads the sender) 

• Some things are probably in the museum ( the client applications used 
to update the displays (via the broker and the sender)) 

• Some things that might be in the museum (the sender and receiver 
webpages themselves, the broker) 

At least that's the idea. We have a working prototype and are still trying to 
understand where the stress points are in the relationship between all the pieces. It's 
true that we could just configure the "receiver" to connect to the "broker" and relay 
messages and screen content that way but then we need to enforce all the logic 
behind what can and can't be shown, and by whom, in to the receiver itself. Which 
introduces extra complexity that become problematic to update easily across 
multiple displays and harder still to debug. 



We prefer to keep the "sender" and "receiver" as simple as possible. The 
receiver is little more than an iframe which can load a URL and a footer which can 
display status messages and other updates. The sender itself is little more than a 
relay mechanism between the broker and the receiver. 

All of the application logic to control the screens lives in the "broker" which 
is itself a node.js server. Right now the list of stuff (URLs) that can be sent to a 
display is hard-coded in the server code itself but eventually we will teach it to talk 
to the API exposed by the content management system that we'll use to generate 
museum signage. Hopefully this enforces a nice clean separation of concerns and 
will make both develop and maintenance easier over time. 



We've put all of this code up on our GitHub 

account https://github.com/cooperhewitt/chromecast-signage and we 

encourage to try and it out and let us know where and when it doesn't work and to 
contribute your fixes. (For example, careful readers will note the poor formatting of 
timestamps in some of the screenshots above...) — thanks to hugovk this particular 
bug has already been fixed! https : //github.com/cooperhewitt/chromecast- 
signage/puii/1 The code is available at: 

https://github.com/cooperhewitt/chromecast-signage 

This is a problem that all museums share and so we are hopeful that this can 
be the first step in developing a lightweight and cost-effective infrastructure to 
deploy dynamic museum signage. 
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SEND SCREEN 


SEND MESSAGE 

send subway schedule to mauipinwale 







This is what a simple "client" application running on a phone might look 
like. In this example we've just sent a webpage containing the schedule for nearby 
subway stations to a "device" named Maui Pinwale. 

We haven't built a tool that is ready to use "out of the box" yet. It probably 
still has some bugs and possibly even some faulty assumptions (in its architecture) 
but we think it's an approach that is worth pursuing and so, in closing, it bears 
repeating that: 

We want the front-of-house staff to be able to update the signage from 
anywhere in the museum using nothing more complicated than the web browser on 
their phone and we want the back-of-house staff to be able to create new content 
(sic) for those displays with nothing more complicated than a webpage. 
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